aboutsummaryrefslogtreecommitdiff
path: root/src/backend/lib/knapsack.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2024-01-18 16:10:57 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2024-01-18 16:11:16 -0500
commit57b440ec115f57ff6e6a3f0df26063822e3123d2 (patch)
treea569fa131439ae14bcf4adbd8e96c0d0986ce1a2 /src/backend/lib/knapsack.c
parente313a611370410f4efe4e816767759870b69dfa6 (diff)
downloadpostgresql-57b440ec115f57ff6e6a3f0df26063822e3123d2.tar.gz
postgresql-57b440ec115f57ff6e6a3f0df26063822e3123d2.zip
Fix plpgsql to allow new-style SQL CREATE FUNCTION as a SQL command.
plpgsql fails on new-style CREATE FUNCTION/PROCEDURE commands within a routine or DO block, because make_execsql_stmt believes that a semicolon token always terminates a SQL command. Now, that's actually been wrong since the day it was written, because CREATE RULE has long allowed multiple rule actions separated by semicolons. But there are few enough people using multi-action rules that there was never an attempt to fix it. New-style SQL functions, though, are popular. psql has this same problem of "does this semicolon really terminate the command?". It deals with CREATE RULE by counting parenthesis nesting depth: a semicolon within parens doesn't end a command. Commits e717a9a18 and 029c5ac03 created a similar heuristic to count matching BEGIN/END pairs (but only within CREATEs, so as not to be fooled by plain BEGIN). That's survived several releases now without trouble reports, so let's just absorb those heuristics into plpgsql. Per report from Samuel Dussault. Back-patch to v14 where new-style SQL function syntax came in. Discussion: https://postgr.es/m/YT2PR01MB88552C3E9AD40A6C038774A781722@YT2PR01MB8855.CANPRD01.PROD.OUTLOOK.COM
Diffstat (limited to 'src/backend/lib/knapsack.c')
0 files changed, 0 insertions, 0 deletions