aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gist.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2025-02-11 12:49:34 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2025-02-11 12:49:34 -0500
commitc366d2bdba7c3b9b2cca1429d4535866e231ca55 (patch)
tree114d1f6c13af036eed4c1a2b0198bf796ad82797 /src/backend/access/gist/gist.c
parent6c7251db0ce12a83dd03c840e7d0ff7516b27229 (diff)
downloadpostgresql-c366d2bdba7c3b9b2cca1429d4535866e231ca55.tar.gz
postgresql-c366d2bdba7c3b9b2cca1429d4535866e231ca55.zip
Allow extension functions to participate in in-place updates.
Commit 1dc5ebc90 allowed PL/pgSQL to perform in-place updates of expanded-object variables that are being updated with assignments like "x := f(x, ...)". However this was allowed only for a hard-wired list of functions f(), since we need to be sure that f() will not modify the variable if it fails. It was always envisioned that we should make that extensible, but at the time we didn't have a good way to do so. Since then we've invented the idea of "support functions" to allow attaching specialized optimization knowledge to functions, and that is a perfect mechanism for doing this. Hence, adjust PL/pgSQL to use a support function request instead of hard-wired logic to decide if in-place update is safe. Preserve the previous optimizations by creating support functions for the three functions that were previously hard-wired. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru> Reviewed-by: Pavel Borisov <pashkin.elfe@gmail.com> Discussion: https://postgr.es/m/CACxu=vJaKFNsYxooSnW1wEgsAO5u_v1XYBacfVJ14wgJV_PYeg@mail.gmail.com
Diffstat (limited to 'src/backend/access/gist/gist.c')
0 files changed, 0 insertions, 0 deletions