Re: Refactor parse analysis of EXECUTE command

Kyotaro Horiguchi <horikyota.ntt@gmail.com>

From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: peter.eisentraut@2ndquadrant.com
Cc: tgl@sss.pgh.pa.us, pgsql-hackers@postgresql.org
Date: 2019-11-05T10:27:48Z
Lists: pgsql-hackers
Hello.

At Mon, 4 Nov 2019 08:53:18 +0100, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote in 
> On 2019-11-02 16:00, Tom Lane wrote:
> > Peter Eisentraut <peter.eisentraut@2ndquadrant.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?

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



Commits

  1. Make better use of ParseState in ProcessUtility

  2. Add error position to an error message

  3. Do parse analysis of an EXPLAIN's contained statement during the normal

  4. First phase of plan-invalidation project: create a plan cache management