Re: cursors with prepared statements

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