From: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: cursors with prepared statements |
Date: | 2018-12-01 11:23:01 |
Message-ID: | CA+q6zcWJifdjoXiqPqiRAqw=EE=DVLksr4kFz=VevwyrU_iqTA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Thu, Nov 22, 2018 at 11:11 AM Dmitry Dolgov <9erthalion6(at)gmail(dot)com> wrote:
>
> > On Wed, Jul 18, 2018 at 10:27 AM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> >
> > On 16/07/18 15:56, Peter Eisentraut wrote:
> > > On 11.07.18 19:07, Heikki Linnakangas wrote:
> > >> It's confusing, and risks conflicting with future additions to
> > >> the standard. ECPG supports the actual standard syntax, with OPEN,
> > >> right? So this wouldn't be consistent with ECPG, either.
> > >
> > > It would be consistent for the case of no parameters.
> >
> > True. Except that if I understand correctly, in the standard syntax you
> > still need to use OPEN after the DECLARE CURSOR, even when there are no
> > parameters.
> >
> > >>> Curiously, the direct EXECUTE statement uses the non-standard syntax
> > >>>
> > >>> EXECUTE prep_stmt (param, param);
> > >>>
> > >>> instead of the standard
> > >>>
> > >>> EXECUTE prep_stmt USING param, param;
> > >>>
> > >>> I tried to consolidate this. But using
> > >>>
> > >>> DECLARE c CURSOR FOR p (foo, bar)
> > >>>
> > >>> leads to parsing conflicts (and looks confusing?),
> > >>
> > >> How about
> > >>
> > >> DECLARE c CURSOR FOR EXECUTE p (foo, bar)
> > >
> > > That's not the standard syntax for the case of no parameters.
> >
> > My thinking here is that "DECLARE c CURSOR FOR <statement>" is standard
> > syntax. And we already have "EXECUTE p (foo, bar)" as a form of
> > statement, along with "SELECT ...", "EXPLAIN ..." and so forth. Allowing
> > "DECLARE c CURSOR FOR EXECUTE p (foo, bar)" would not introduce a new
> > syntax, it would just allow the existing two commands, DECLARE CURSOR,
> > and EXECUTE, to be used together.
>
> This patch went through the last few commitfests without any noticeable
> activity. Both suggested patches are still good (can be applied and passed all
> the tests, except the minor text mismatch in the original one), but looks like
> the discussion stopped right in the middle. Are there any more opinions about
> OPEN vs DECLARE .. CURSOR FOR here or any other plans about the patch?
I hope it's not another abandoned patch, but due to lack of response I'm
marking it as returned with feedback. If someone didn't see my previous
inquiry and ready to continue working on this patch - feel free to change it
back.
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Dolgov | 2018-12-01 11:47:13 | Re: Online verification of checksums |
Previous Message | Simon Riggs | 2018-12-01 10:51:10 | Re: pgsql: Avoid duplicate XIDs at recovery when building initial snapshot |