út 5. 11. 2019 v 11:28 odesílatel Kyotaro Horiguchi <horikyota....@gmail.com> napsal:
> Hello. > > At Mon, 4 Nov 2019 08:53:18 +0100, Peter Eisentraut < > peter.eisentr...@2ndquadrant.com> wrote in > > On 2019-11-02 16:00, Tom Lane wrote: > > > Peter Eisentraut <peter.eisentr...@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 > > >
