| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Jaime Casanova" <systemguards(at)gmail(dot)com> |
| Cc: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Merlin Moncure" <mmoncure(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: savepoint improvements |
| Date: | 2007-01-21 18:28:08 |
| Message-ID: | 28000.1169404088@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Jaime Casanova" <systemguards(at)gmail(dot)com> writes:
> On 1/21/07, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> - continue on error i.e. COMMIT can/might succeed - though there are
>> still cases where it cannot, such as a serializable exception.
> and what should be the behaviour of that? the same as rollback?
The only conceivable implementation is an implicit savepoint issued
before each statement. By and large that seems to me to be most easily
handled on the client side, and many of our client libraries already
have the ability to do it. (For instance, psql has ON_ERROR_ROLLBACK.)
If we tried to do it on the server side, we would break any client
software that wasn't prepared for the change of behavior --- see the 7.3
autocommit fiasco for an example.
So as far as the server is concerned, I see no TODO here.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joshua D. Drake | 2007-01-21 18:37:45 | Re: savepoint improvements |
| Previous Message | Tom Lane | 2007-01-21 17:54:17 | Re: Simplifying pg_am representation of index sortability |