From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl> |
Cc: | Oliver Jowett <oliver(at)opencloud(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [Re] Re: PREPARE and transactions |
Date: | 2004-07-03 03:05:07 |
Message-ID: | 16464.1088823907@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Jeroen T. Vermeulen" <jtv(at)xs4all(dot)nl> writes:
> I guess the question then becomes: should we see the frontend-backend
> protocol as a transport layer underneath, and conceptually separate from,
> the SQL session? Or should the protocol be allowed to shine through in
> the way SQL itself is supported, and vice versa, so the two can share code
> and concepts?
One point here is that in the present design, statements prepared via
SQL-level PREPARE are intentionally interchangeable with statements
prepared via protocol-level Prepare messages. You can create a
statement either way and then use it at either level. Perhaps this was
a bad idea. I think that if we decide to make the semantics of PREPARE
and Prepare different, it would be wise to separate the statement
namespaces so that PREPARE'd and Prepare'd statements are totally
independent.
It's late at night and I'm too lazy to go look right now, but I think
that the same is true of SQL-level cursors and protocol-level portals.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Abhijit Menon-Sen | 2004-07-03 03:07:23 | Re: PREPARE and transactions |
Previous Message | Oliver Jowett | 2004-07-03 02:59:58 | Re: [Re] Re: PREPARE and transactions |