Skip site navigation (1) Skip section navigation (2)

Re: TODO: Add a GUC to control whether BEGIN inside

From: "news(dot)postgresql(dot)org" <smith(at)pooteeweet(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: TODO: Add a GUC to control whether BEGIN inside
Date: 2007-01-02 16:34:05
Message-ID: 459A897D.1060601@pooteeweet.org (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> Am Donnerstag, 28. Dezember 2006 18:57 schrieb Bruce Momjian:
>>> I think you can make the case that this should be an error, or at least
>>> that's how it got on the TODO list.  I can always remove it if people
>>> don't want the item completed.
> 
>> The reason this was added is that modular applications expect that a locally 
>> issued BEGIN ... COMMIT executes a transaction, whereas now you don't know 
>> what you're getting.  I think this change would have merit.
> 
> But how is making BEGIN an error going to improve life for such an
> application?  It'll be just as broken.  In fact, if the app depends on
> getting an error from BEGIN in any critical way, it'll be *more* broken
> if it's ever run under the default warning-only setting.

While we are on the topic, I have implemented a poor mans nested 
transaction feature into my database access layer. essentially 
subsequent calls to begin a transaction after the initial begin simply 
increase an internal counter and set a savepoint. as you commit the 
transactions the counter is decreased and the savepoints are released. 
maybe this could be implemented inside postgresql to make the life of 
modular programmers easier?

regards,
Lukas

In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2007-01-02 16:42:36
Subject: Re: TODO: Add a GUC to control whether BEGIN inside
Previous:From: Tom LaneDate: 2007-01-02 15:19:38
Subject: Re: effective_cache_size vs units

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group