Re: Surprising behaviour of \set AUTOCOMMIT ON - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Surprising behaviour of \set AUTOCOMMIT ON
Date
Msg-id CAA4eK1KW-_gT8aJ1qLF6T8q3eC7s8UuY-V6dHNemvmi621uwjA@mail.gmail.com
Whole thread Raw
In response to Re: Surprising behaviour of \set AUTOCOMMIT ON  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-hackers
On Sat, Aug 13, 2016 at 1:05 AM, David G. Johnston
<david.g.johnston@gmail.com> wrote:
>
> I'll admit I haven't tried to find fault with the idea (or discover better
> alternatives) nor how it would look in implementation.  As a user, though,
> it would make sense if the system behaved in this way.  That only AUTOCOMMIT
> needs this capability at the moment doesn't bother me.  I'm also fine with
> making it an error and moving on - but if you want to accommodate both
> possibilities this seems like a cleaner solution than yet another
> environment variable that a user would need to consider.
>

I agree on your broad point that we should consider user convenience,
but  in this case I am not sure if it will be convenient for a user to
make the behaviour dependent on value of ON_ERROR_STOP.  I have
checked this behaviour in one of the top commercial database and it
just commits the previous transaction after the user turns the
Autocommit to on and the first command is complete.  I am not saying
that we should blindly follow that behaviour, but just to indicate
that it should be okay for users if we don't try to define multiple
behaviours here based on value of ON_ERROR_STOP.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: Slowness of extended protocol
Next
From: konstantin knizhnik
Date:
Subject: Re: WIP: Barriers