Tom Lane fdc7cf73b4 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		2023-09-25 14:41:57 -04:00
..
plperl	Translation updates	2023-05-08 14:44:53 +02:00
plpgsql	Collect dependency information for parsed CallStmts.	2023-09-25 14:41:57 -04:00
plpython	Fix assertion failure with PL/Python exceptions	2023-09-19 08:31:31 +09:00
tcl	Translation updates	2023-05-08 14:44:53 +02:00
Makefile	Make distprep and *clean build targets recurse into all subdirectories.	2011-07-03 13:55:12 -04:00