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?
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
