Re: Refactor parse analysis of EXECUTE command - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: Refactor parse analysis of EXECUTE command
Date
Msg-id 20191105.192748.1701463140016431677.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: Refactor parse analysis of EXECUTE command  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: Refactor parse analysis of EXECUTE command  (Pavel Stehule <pavel.stehule@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: rtorre@carto.com
Date:
Subject: Re: [Proposal] Arbitrary queries in postgres_fdw
Next
From: Grigory Smolkin
Date:
Subject: Re: [proposal] recovery_target "latest"