From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Jaime Casanova" <systemguards(at)gmail(dot)com>, "Merlin Moncure" <mmoncure(at)gmail(dot)com>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: savepoint improvements |
Date: | 2007-01-22 08:46:02 |
Message-ID: | 1169455562.3776.213.camel@silverbirch.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, 2007-01-21 at 13:28 -0500, Tom Lane wrote:
> "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?
No. The behaviour is to continue the transaction even though an error
has occurred, i.e.
BEGIN;
1. INSERT...
success
2. INSERT .... VALUES () () ()
--fails with error on 3rd VALUES statement
dynamically re-construct INSERT statement with remaining 2 VALUES
statements
3. INSERT VALUES () ();
success
COMMIT;
work done by 1 and 3 is committed
Behaviour needs to support any error at (2) except serializable
exceptions.
> The only conceivable implementation is an implicit savepoint issued
> before each statement.
Perhaps the only acceptable one.
> 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.
PL/pgSQL supports EXCEPTIONs, but no other clients support it, AFAICS.
> (For instance, psql has ON_ERROR_ROLLBACK.)
Thats not the same thing, regrettably.
> 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.
Only if we changed the default behaviour, which I am not suggesting.
> So as far as the server is concerned, I see no TODO here.
If the server team won't allow it, we must document that this behaviour
must be a client-side function in the *server* TODO, so that all the
various client projects can read the same TODO item and implement it.
"Implement continue-on-error transactional behaviour for each client
library".
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2007-01-22 09:09:42 | Re: [HACKERS] Autovacuum Improvements |
Previous Message | Tom Lane | 2007-01-22 07:07:00 | Re: DROP FUNCTION failure: cache lookup failed for relation X |