| 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: | Whole Thread | Raw Message | 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 |