From: | Michael Meskes <meskes(at)postgresql(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Michael Meskes <meskes(at)postgresql(dot)org>, PostgreSQL Hacker <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Prepare/Declare |
Date: | 2007-05-27 12:21:50 |
Message-ID: | 20070527122150.GA25883@feivel.credativ.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, May 24, 2007 at 04:07:27PM -0400, Tom Lane wrote:
> 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>.
Sorry, should have been more precise. I was talking about embedded SQL
standard. Just look for "dynamic cursors".
> 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.
I could also keep my old simultaing code for this special case, which is
probably the best way to do it.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes(at)jabber(dot)org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-05-27 16:05:44 | Re: Prepare/Declare |
Previous Message | Michael Meskes | 2007-05-27 11:33:28 | Re: ecpg test runs out of disk space |