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, 11.
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 kleptog@svana.org writes:
How do other database deal with this? Either they nest BEGIN/COMMIT or
they probably throw an error without aborting the transaction,
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 kleptog@svana.org writes:
How do other database deal with this? Either they nest BEGIN/COMMIT or
they
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; COMMIT;
On 5/11/06, Martijn van Oosterhout kleptog@svana.org 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,
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 Wed, 2006-05-10 at 21:24 -0400, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org 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
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
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
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
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 function
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.
I
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 the
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 have its own
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 had a PHP
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.
That
--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: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 command doesn't do
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
know of
--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.
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
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
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
quote
Lastly, StartTrans/CompleteTrans is nestable, and only the outermost
block is executed. In
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, instead
---
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 aborted transaction?
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 existing
Martijn van Oosterhout kleptog@svana.org 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
On 5/10/06, Tom Lane [EMAIL PROTECTED] wrote:
Martijn van Oosterhout kleptog@svana.org 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
Tom Lane skrev:
The SQL99 spec does say (in describing START TRANSACTION,
which is the standard spelling of BEGIN)
1) If a start transaction statement statement is executed when an
SQL-transaction is currently active, then an exception condition
is raised:
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
30 matches
Mail list logo
