-----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@turnstep.com
PGP Key: 0x14964AC8 200503121836
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iD8DBQFCM30WvJuQZxSWSsgRAryZAKCyIDYd36mAaU464AbPkHe9zkYI+QCfU+Fb
7A2WJwLJcOvzJDHjRnr55v4=
=UJ8E
-----END PGP SIGNATURE-----
