On 2019-11-08 08:13, Pavel Stehule wrote: > I dug into repository and found that transformExecuteStmt existed at > the time of implementing PREPARE-EXECUTE statements(28e82066a1) and > removed by the commit b9527e9840 which is related to > plan-invalidation. > > git show -s --format=%B b9527e984092e838790b543b014c0c2720ea4f11 > > In service of this, rearrange utility-statement processing so > that parse > > analysis does not assume table schemas can't change before > execution for > > utility statements (necessary because we don't attempt to > re-acquire locks > > for utility statements when reusing a stored plan). This > requires some > > Isn't this related to the current structure? > > I think so it should be ok, because the transformation is still in same > statement - if I understand well. > > So visibility of system catalogue or access to plan cache should not be > changed.
I think what that patch was addressing is, if you use a protocol-level prepare+execute with commands like CREATE INDEX, CREATE VIEW, or COPY and you change the table schema between the prepare and execute, things would break, for the reasons explained in the commit message. So any parse analysis in utility statements that accesses table schemas needs to be done in the execute phase, not in the prepare phase, as one might think.
Parse analysis of EXECUTE does not access any tables, so if I understood this correctly, this concern doesn't apply here.
it should not be true - the subquery can be a expression.
Minimally on SQL level is not possible do prepare on execute. So execute should be evaluate as one step.
Interestingly, the above commit also removed the prepare-time transformation of ExplainStmt, but it was later put back and now has the comment "We used to postpone that until execution, but it's really necessary to do it during the normal parse analysis phase to ensure that side effects of parser hooks happen at the expected time." So there appears to be a generally uneasy situation still about how to do this correctly.
Perhaps something could be done about the issue "because we don't attempt to re-acquire locks for utility statements when reusing a stored plan"?
-- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
