Re: Continue transactions after errors in psql

From: "Greg Sabino Mullane" <greg(at)turnstep(dot)com>
To: pgsql-patches(at)postgresql(dot)org
Subject: Re: Continue transactions after errors in psql
Date: 2005-03-13 13:38:38
Message-ID: ce92cf1f25411d6a6d02bd27faad9d1a@biglumber.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Lane wrote:
> I don't have a good solution, but I do think that you need to set things
> up so that an application or script must invoke the new behavior
> explicitly. Hidden defaults that silently change such behavior look
> like land mines waiting to be stepped on.

Michael Paesold wrote:
> I think without tty-detection, the patch just conflicts with PostgreSQL
> philosophy that the user should be kept save from unintended
> data-destruction.

I don't know if I would go that far. This is a setting that must be explicitly
enabled, so it's more a case of caveat emptor is you choose to enable it.
I don't like the idea of the behavior changing so radically just depending
on the tty state. Maybe if we call it "ttyonly" or something instead of
"auto"...?

> The SQL-Standard itself says that errors inside transactions should only
> rollback the last statement, if possible. So why is that not implemented in
> PostgreSQL? What I read from past discussions here, is because it's just
> unsave and will lead to data-garbage if you aren't very careful.

That's a good point: if that is indeed what the standard says, we should
probably see about following it. Rolling back to the last savepoint seems
a reasonable behavior to me.

> The current way is ok for me at the moment. I still think there is a better
> way (parsing statements like it's already done for
> no-transaction-allowed-statements), but hey, as soon as your patch will be
> applied, I can myself propose another patch to improve this. ;-)

Parsing the statment will not help: even if the statement is a savepoint, we
need to wrap it in case we need to roll it back. The only other option I
can see to my patch is to, upon a successful user savepoint creation,
roll back their savepoint and immediately reissue it. That seems worse to
me than having N*2 savepoints though.

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 200503121836
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iD8DBQFCM30WvJuQZxSWSsgRAryZAKCyIDYd36mAaU464AbPkHe9zkYI+QCfU+Fb
7A2WJwLJcOvzJDHjRnr55v4=
=UJ8E
-----END PGP SIGNATURE-----

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Sabino Mullane 2005-03-13 14:18:12 Re: TODO item: support triggers on columns
Previous Message Andrew - Supernews 2005-03-13 13:22:10 Re: Bumping libpq version number?

Browse pgsql-patches by date

  From Date Subject
Next Message Greg Stark 2005-03-13 22:35:27 Re: [PATCHES] A way to let Vacuum warn if FSM settings are low. [final?]
Previous Message Marko Kreen 2005-03-13 12:40:22 Re: pgcrypto: openssl digest fix