Added to TODO:
* Add a GUC to control whether BEGIN inside a transcation should abort
the transaction.
---
Jaime Casanova wrote:
> On 5/12/06, Mario Weilguni <[EMAIL PROTECTED]> wrote:
> > Am Donnerstag,
On 5/12/06, Mario Weilguni <[EMAIL PROTECTED]> wrote:
Am Donnerstag, 11. Mai 2006 22:16 schrieb Simon Riggs:
> On Wed, 2006-05-10 at 21:24 -0400, Tom Lane wrote:
> > Martijn van Oosterhout writes:
> > > How do other database deal with this? Either they nest BEGIN/COMMIT or
> > > they probably th
Am Donnerstag, 11. Mai 2006 22:16 schrieb Simon Riggs:
> On Wed, 2006-05-10 at 21:24 -0400, Tom Lane wrote:
> > Martijn van Oosterhout writes:
> > > How do other database deal with this? Either they nest BEGIN/COMMIT or
> > > they probably throw an error without aborting the transaction, which is
On Wed, 2006-05-10 at 21:24 -0400, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > How do other database deal with this? Either they nest BEGIN/COMMIT or
> > they probably throw an error without aborting the transaction, which is
> > pretty much what we do. Is there a database that actually a
On Thu, May 11, 2006 at 08:05:57AM +0200, Tommi Maekitalo wrote:
> I'd vote for breaking broken applications and leave the
> database-administrator
> reactivate this currently broken behavior of postgresql via GUC.
+1...
As for whether this should or shouldn't abort the current transaction,
I'd
On 5/11/06, Martijn van Oosterhout wrote:
On Wed, May 10, 2006 at 04:03:51PM -0500, Jim C. Nasby wrote:
> If the existing application is trying to start a new transaction from
> within an existing one, I'd say it's already broken and we're just
> hiding that fact.
Well maybe, except the extra B
Am Mittwoch, 10. Mai 2006 22:23 schrieb Mark Dilger:
> Martijn van Oosterhout wrote:
> > On Wed, May 10, 2006 at 09:41:46AM +0200, Mario Weilguni wrote:
> Could we make BEGIN fail when we already are in a transaction?
...
>
> Or if you really want to screw things up, you could require COMMIT; C
Tom Lane skrev:
The SQL99 spec does say (in describing START TRANSACTION,
which is the standard spelling of BEGIN)
1) If a statement is executed when an
SQL-transaction is currently active, then an exception condition
is raised: invalid transaction state - activ
On 5/10/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Martijn van Oosterhout writes:
> How do other database deal with this? Either they nest BEGIN/COMMIT or
> they probably throw an error without aborting the transaction, which is
> pretty much what we do. Is there a database that actually aborts a
>
Martijn van Oosterhout writes:
> How do other database deal with this? Either they nest BEGIN/COMMIT or
> they probably throw an error without aborting the transaction, which is
> pretty much what we do. Is there a database that actually aborts a
> whole transaction just for an extraneous begin?
On Wed, May 10, 2006 at 04:03:51PM -0500, Jim C. Nasby wrote:
> On Wed, May 10, 2006 at 12:31:52PM +0200, Mario Weilguni wrote:
> > Maybe. I just want to emphasize that it will break existing applications.
>
> If the existing application is trying to start a new transaction from
> within an existi
On Wed, May 10, 2006 at 12:31:52PM +0200, Mario Weilguni wrote:
> Am Mittwoch, 10. Mai 2006 10:59 schrieb Peter Eisentraut:
> > Am Mittwoch, 10. Mai 2006 10:10 schrieb Martijn van Oosterhout:
> > > You want to make a GUC that makes:
> > >
> > > BEGIN;
> > > BEGIN;
> > >
> > > Leave you with an abor
Martijn van Oosterhout wrote:
> On Wed, May 10, 2006 at 09:41:46AM +0200, Mario Weilguni wrote:
>
Could we make BEGIN fail when we already are in a transaction?
>>>
>>>We could, but it'd probably break about as many apps as it fixed.
>>>I wonder whether php shouldn't be complaining about this,
I would suggest the guy simply use the popular ADODB package for his
database abstraction layer so he can make use of its "Smart Transaction"
feature.
http://phplens.com/lens/adodb/docs-adodb.htm#ex11
Lastly, StartTrans/CompleteTrans is nestable, and only the outermost
block is executed. In con
I dont think anyone is arguing that such an application is not
broken. We should see how we can stop a developer from writing buggy
code.
IMO, such a GUC variable _should_ be created and turned on by default.
In case an application fails, at the least, the developer knows
that his appli
Peter Eisentraut skrev:
Am Mittwoch, 10. Mai 2006 10:10 schrieb Martijn van Oosterhout:
You want to make a GUC that makes:
BEGIN;
BEGIN;
Leave you with an aborted transaction? That seems like a singularly
useless feature...
If a command doesn't do what it is supposed to do, then it s
--On Mittwoch, Mai 10, 2006 12:36:07 +0200 Mario Weilguni
<[EMAIL PROTECTED]> wrote:
Such a behavior is already broken by design. I think it's not desirable
to blindly do
transaction start or commit without tracking the current transaction
state. So these wrappers
need to be fixed first.
Y
Am Mittwoch, 10. Mai 2006 11:44 schrieb Bernd Helmle:
> --On Mittwoch, Mai 10, 2006 10:14:22 +0200 Mario Weilguni
>
> <[EMAIL PROTECTED]> wrote:
> > No, I want that there is a setting or GUC that controls whether an error
> > or a warning is raised when "begin" is executed within a transaction. I
Am Mittwoch, 10. Mai 2006 10:59 schrieb Peter Eisentraut:
> Am Mittwoch, 10. Mai 2006 10:10 schrieb Martijn van Oosterhout:
> > You want to make a GUC that makes:
> >
> > BEGIN;
> > BEGIN;
> >
> > Leave you with an aborted transaction? That seems like a singularly
> > useless feature...
>
> If a co
--On Mittwoch, Mai 10, 2006 10:14:22 +0200 Mario Weilguni
<[EMAIL PROTECTED]> wrote:
No, I want that there is a setting or GUC that controls whether an error
or a warning is raised when "begin" is executed within a transaction. I
know of several php database wrappers that will be seriously
Am Mittwoch, 10. Mai 2006 10:10 schrieb Martijn van Oosterhout:
> You want to make a GUC that makes:
>
> BEGIN;
> BEGIN;
>
> Leave you with an aborted transaction? That seems like a singularly
> useless feature...
If a command doesn't do what it is supposed to do, then it should be an error.
Tha
Am Mittwoch, 10. Mai 2006 09:41 schrieb Mario Weilguni:
> Am Mittwoch, 10. Mai 2006 08:19 schrieb Tom Lane:
> > Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> > > Yesterday I helped a guy on irc with a locking problem, he thought
> > > that locking in postgresql was broken. It turned out that he ha
On Wed, May 10, 2006 at 09:41:46AM +0200, Mario Weilguni wrote:
> > > Could we make BEGIN fail when we already are in a transaction?
> >
> > We could, but it'd probably break about as many apps as it fixed.
> > I wonder whether php shouldn't be complaining about this, instead
> > --- doesn't php ha
Am Mittwoch, 10. Mai 2006 08:19 schrieb Tom Lane:
> Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> > Yesterday I helped a guy on irc with a locking problem, he thought
> > that locking in postgresql was broken. It turned out that he had a PHP
> > function that he called inside his transaction and t
Tom Lane wrote:
> Dennis Bjorklund <[EMAIL PROTECTED]> writes:
>> Could we make BEGIN fail when we already are in a transaction?
>
> We could, but it'd probably break about as many apps as it fixed.
I'd say that a program that issues BEGIN inside a transaction is
already broken, if only by design
On 5/10/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> Yesterday I helped a guy on irc with a locking problem, he thought
> that locking in postgresql was broken. It turned out that he had a PHP
> function that he called inside his transaction and the funct
Tom Lane wrote:
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
Yesterday I helped a guy on irc with a locking problem, he thought
that locking in postgresql was broken. It turned out that he had a PHP
function that he called inside his transaction and the function did BEGIN
and COMMIT. Since BEGIN
We could, but it'd probably break about as many apps as it fixed.
I wonder whether php shouldn't be complaining about this, instead
--- doesn't php have its own ideas about controlling where the
transaction commit points are?
All PHP does is when the connection is returned to the pool, if it is
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> Yesterday I helped a guy on irc with a locking problem, he thought
> that locking in postgresql was broken. It turned out that he had a PHP
> function that he called inside his transaction and the function did BEGIN
> and COMMIT. Since BEGIN inside a t
Hi
Yesterday I helped a guy on irc with a locking problem, he thought
that locking in postgresql was broken. It turned out that he had a PHP
function that he called inside his transaction and the function did BEGIN
and COMMIT. Since BEGIN inside a transaction is just a warning what
happend was th
30 matches
Mail list logo
