]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Collect dependency information for parsed CallStmts.
authorTom Lane <tgl@sss.pgh.pa.us>
Mon, 25 Sep 2023 18:41:57 +0000 (14:41 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Mon, 25 Sep 2023 18:41:57 +0000 (14:41 -0400)
commit4435a8d5dbabbe41fc1c4b7b8dff34902853a07b
tree618ca93506ee6b10c19052f2fbd594340bb39ce4
parent4a81ed29d3c956ad11354c0dc4514f5af4a0d8d7
Collect dependency information for parsed CallStmts.

Parse analysis of a CallStmt will inject mutable information,
for instance the OID of the called procedure, so that subsequent
DDL may create a need to re-parse the CALL.  We failed to detect
this for CALLs in plpgsql routines, because no dependency information
was collected when putting a CallStmt into the plan cache.  That
could lead to misbehavior or strange errors such as "cache lookup
failed".

Before commit ee895a655, the issue would only manifest for CALLs
appearing in atomic contexts, because we re-planned non-atomic
CALLs every time through anyway.

It is now apparent that extract_query_dependencies() probably
needs a special case for every utility statement type for which
stmt_requires_parse_analysis() returns true.  I wanted to add
something like Assert(!stmt_requires_parse_analysis(...)) when
falling out of extract_query_dependencies_walker without doing
anything, but there are API issues as well as a more fundamental
point: stmt_requires_parse_analysis is supposed to be applied to
raw parser output, so it'd be cheating to assume it will give the
correct answer for post-parse-analysis trees.  I contented myself
with adding a comment.

Per bug #18131 from Christian Stork.  Back-patch to all supported
branches.

Discussion: https://postgr.es/m/18131-576854e79c5cd264@postgresql.org
src/backend/optimizer/plan/setrefs.c
src/pl/plpgsql/src/expected/plpgsql_call.out
src/pl/plpgsql/src/sql/plpgsql_call.sql