Re: Refactor parse analysis of EXECUTE command

út 5. 11. 2019 v 11:28 odesílatel Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
napsal:

> Hello.
>
> At Mon, 4 Nov 2019 08:53:18 +0100, Peter Eisentraut <
> peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote in
> > On 2019-11-02 16:00, Tom Lane wrote:
> > > Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> > >> This patch moves the parse analysis component of ExecuteQuery() and
> > >> EvaluateParams() into a new transformExecuteStmt() that is called from
> > >> transformStmt().
> > > Uhmm ... no actual patch attached?
> >
> > Oops, here it is.
>
> The patch just moves the first half of EvaluateParams that is
> irrelevant to executor state to before portal parameters are set. I
> looked with a suspect that extended protocol or SPI are affected but
> AFAICS it doesn't seem to.
>
> 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.

Regards

Pavel

> regards.
>
> --
> Kyotaro Horiguchi
> NTT Open Source Software Center
>
>
>