On Sun, 2007-01-21 at 13:28 -0500, Tom Lane wrote: > "Jaime Casanova" <[EMAIL PROTECTED]> writes: > > On 1/21/07, Simon Riggs <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster