pá 8. 11. 2019 v 8:54 odesílatel Peter Eisentraut < peter.eisentr...@2ndquadrant.com> napsal:
> 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 >
