Re: Refactor parse analysis of EXECUTE command

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Refactor parse analysis of EXECUTE command
Date: 2019-11-08 07:38:57
Message-ID: CAFj8pRAcESbEF0f6BErP330i7bn2bJbaWjO182jxhc_O84uB0g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

po 4. 11. 2019 v 8:53 odesílatel Peter Eisentraut <
peter(dot)eisentraut(at)2ndquadrant(dot)com> napsal:

> On 2019-11-02 16:00, Tom Lane wrote:
> > Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)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.
>

I checked this patch, and I think so it's correct and wanted. It introduce
transform stage for EXECUTE command, and move there the argument
transformation.

This has sensible change - the code is much more correct now.

The patching, compilation was without any problems, make check-world too.

I was little bit confused about regress tests - the patch did some code
refactoring and I expect so main target is same behave before and after
patching. But the regress tests shows new feature that is just side effect
(nice) of patch. More, the example is little bit strange - nobody will use
prepared statements and execution in SQL function. It should be better
commented.

I'll mark this patch as ready for commiters.

Regards

Pavel

> --
> Peter Eisentraut http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message 曾文旌 (义从) 2019-11-08 07:50:42 Re: [Proposal] Global temporary tables
Previous Message Amit Langote 2019-11-08 07:24:10 Re: Exposure related to GUC value of ssl_passphrase_command