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-27 16:05:44 |
Message-ID: | 14440.1180281944@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:
> On Thu, May 24, 2007 at 04:07:27PM -0400, Tom Lane wrote:
>> 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".
Oh, I see what you're looking at. But my point here is that this
version of PREPARE has zip to do with ours: it seems more akin to
plpgsql's EXECUTE, since AFAICT you are supposed to give it a string
value that then gets parsed as a SQL statement. Also it lacks any
way to define parameters for the statement.
> I could also keep my old simultaing code for this special case, which is
> probably the best way to do it.
Yeah, I think keeping this version of PREPARE on the ecpg side is
probably best.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-05-27 16:42:45 | Re: buildfarm failures after pgstat patch |
Previous Message | Michael Meskes | 2007-05-27 12:21:50 | Re: Prepare/Declare |