Re: [HACKERS] New parameter RollbackError to control rollback behavior on error

(Moving back this thread to pgsql-odbc, so keeping a maximum of message history)

On Wed, Mar 26, 2014 at 5:53 PM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> On 03/26/2014 08:39 AM, Michael Paquier wrote:
>> The behavior of rollback when an error occurs on an handle is
>> controlled by extending Protocol with "$PROTNUM-[0|1|2]" where:
>> - 0 = let the application handle rollbacks
>> - 1 = rollback whole transaction when an error occurs
>> - 2 = rollback only statement that failed
>> Using such an extension is somewhat awkward as a single string is used
>> for two settings... The proposed attached patch adds a new parameter
>> called RollbackError that allows to control the behavior of rollback
>> on error with a different parameter.
> Since we're designing a new user interface for this, let's try to make it as
> user-friendly as possible:
>
> * I'm not too fond of the RollbackError name. It sounds like "an error while
> rolling back". I googled around and found out that DataDirect's proprietary
> driver has the same option, and they call it TransactionErrorBehavior. See
> http://blogs.datadirect.com/2013/07/solution-unexpected-postgres-current-transaction-aborted-error.html.
Yeah, sounds fine... I am not coming with a better name now.

> * Instead of using 0-2 as the values, let's give them descriptive names.
> Something like "none", "RollbackTransaction", "RollbackStatement".
> (actually, we'll probably want to also allow the integers, to keep the
> connection string short, as there is a size limit on that)
Good idea. I'd vote for using only the strings in the new parameter
for simplicity, and to mention in the docs to which integer value maps
each string. We could as well use MEDIUM_REGISTRY_LEN (256 characters)
to control the size limit of the new parameter string.

>> I thought first about including that in my cleanup work for 9.4, but
>> as this actually does not break the driver it may be worth adding it
>> directly to master, explaining the patch attached here. Comments
>> welcome. Note that if there are objections I do not mind adding that
>> for the work that would be merged later to 9.4 builds.
>
> Yeah, let's get this into the master branch before your big 9.4 cleanup
> work.
OK, so I'll hack a patch following those lines. I shall be able to get
that soon with regression tests.
Regards,
--
Michael