Re: Refactor parse analysis of EXECUTE command
От | Kyotaro Horiguchi |
---|---|
Тема | Re: Refactor parse analysis of EXECUTE command |
Дата | |
Msg-id | 20191105.192748.1701463140016431677.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: Refactor parse analysis of EXECUTE command (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: Refactor parse analysis of EXECUTE command
|
Список | 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 по дате отправления: