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
-
Make better use of ParseState in ProcessUtility
- 3fd40b628c7d 13.0 landed
-
Add error position to an error message
- d4feadeca159 13.0 landed
-
Do parse analysis of an EXPLAIN's contained statement during the normal
- 08f8d478ebc3 9.0.0 cited
-
First phase of plan-invalidation project: create a plan cache management
- b9527e984092 8.3.0 cited