Re: Refactor parse analysis of EXECUTE command

pá 8. 11. 2019 v 8:54 odesílatel Peter Eisentraut <
peter(dot)eisentraut(at)2ndquadrant(dot)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
>