From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Meskes <meskes(at)postgresql(dot)org> |
Cc: | PostgreSQL Hacker <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Prepare/Declare |
Date: | 2007-05-24 20:07:27 |
Message-ID: | 20209.1180037247@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Meskes <meskes(at)postgresql(dot)org> writes:
> PREPARE p AS
> SELECT * FROM foo;
> DECLARE c CURSOR for p;
> AFAIRC the standard says this group of statements are perfectly legal
I'd be interested to see where you draw that conclusion, since
(a) PREPARE statements of that form are not in the standard, and
(b) DECLARE CURSOR is clearly defined as taking a <query expression>.
It doesn't seem like an amazingly sensible thing to do, either.
DECLARE CURSOR affects the plan generated for its query (eg,
backwards-scrollability may be required), so it's not certain that
a previously PREPARE'd plan could be used.
You can achieve something approximating this at the protocol level,
since you can do partial fetches from a portal created by Bind'ing
the prepared statement. That won't let you fetch backwards nor
persist the cursor past end of transaction, but maybe you don't
need those things.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2007-05-24 20:12:48 | Re: Concurrent psql patch |
Previous Message | Michael Meskes | 2007-05-24 19:40:39 | Prepare/Declare |