Re: Refactor parse analysis of EXECUTE command

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.

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