Am Mittwoch, 10. Mai 2006 09:41 schrieb Mario Weilguni:
> Am Mittwoch, 10. Mai 2006 08:19 schrieb Tom Lane:
> > Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org> 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 transaction is just a warning
> > > what happend was that the inner COMMIT ended the transaction and
> > > released the locks. The rest of his commands ran with autocommit
> > > and no locks and he got broken data into the database.
> > >
> > > 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 have its own ideas about controlling where the
> > transaction commit points are?
>
> In fact it would break many application, so it should be at least
> controllable by a setting or GUC.
>
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 broken when errors are
raised...