From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl> |
Cc: | Merlin Moncure <merlin(dot)moncure(at)rcsonline(dot)com>, pgsql-hackers(at)postgresql(dot)org, Richard Huxton <dev(at)archonet(dot)com> |
Subject: | Re: PREPARE and transactions |
Date: | 2004-06-24 14:26:34 |
Message-ID: | 13817.1088087194@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 think we're talking at cross purposes here... If the client doesn't use
> explicit transactions, as you say is common, then you're obviously not
> defining prepared statements inside explicit transactions either.
This whole discussion seems to be considering only the case of PREPAREs
issued as SQL statements, by a programmer who is fully cognizant of
where he's beginning and ending transactions.
The issue I was trying to raise at the beginning of the thread was: what
about prepared statements created by client libraries (think JDBC for
instance) using the V3 protocol Parse message? Rolling back a
successful prepare because of a later transaction failure seems like
exactly not what such a library would want.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Hallgren | 2004-06-24 14:38:47 | Re: warning missing |
Previous Message | Jeroen T. Vermeulen | 2004-06-24 14:09:37 | Re: PREPARE and transactions |