Re: Statement-level rollback - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Statement-level rollback
Date
Msg-id 20181207210931.jm63m4gmq5hgwm75@alap3.anarazel.de
Whole thread Raw
In response to Re: Statement-level rollback  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Statement-level rollback
List pgsql-hackers
Hi,

On 2018-12-07 16:02:53 -0500, Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > Well, look at this from this point of view: EnterpriseDB implemented
> > this because of customer demand (presumably).  Fujitsu also implemented
> > this for customers.  The pgjdbc driver implemented this for its users.
> > Now 2ndQuadrant also implemented this, and not out of the goodness of
> > our hearts.  Is there any room to say that there is no customer demand
> > for this feature?
> 
> Yeah, but there is also lots of demand for stability in basic
> transactional semantics.  I refer you again to the AUTOCOMMIT business;
> there were a lot of claims that that wouldn't break too much, and they
> were all wrong.

I think it could partially be addressed by not allowing to set it on the
commandline, server config, etc. So the user would have to set it on a
per-connection basis, potentially via the connection string.

I'm quite concerned how this'll make it much harder to write UDFs that
work correctly. If suddenly the error handling expected doesn't work
anymore - because they an error just skips over a statements - a lot of
things will break in hard to understand ways.

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Statement-level rollback
Next
From: Greg Stark
Date:
Subject: Thinking about EXPLAIN ALTER TABLE