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-----
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? |
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 |