Re: cursors with prepared statements

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: cursors with prepared statements
Date: 2018-07-18 08:26:44
Message-ID: c8566a17-66fa-f95b-4e8d-cfad6fa12cbb@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2018-07-18 08:29:19 Re: Speeding up INSERTs and UPDATEs to partitioned tables
Previous Message Michael Paquier 2018-07-18 08:18:18 Re: Incorrect error handling for two-phase state files resulting in data loss