Greg Sabino Mullane wrote:
>> * You have not yet implemented a way to savely put \reseterror
>> in .psqlrc. I previously suggested an AUTO setting (additional
>> to ON/OFF) that disables \reseterror when reading from a non-tty.
>> So putting \reseterror AUTO in ..psqlrc would be save.
>
> Hmm...I suppose we could do that. Do we have anything else that
> does something similar? I guess I'm not convinced that we need
> to change a switch's behavior based on the tty status.
I do think so. In it's current state, would you yourself put \reseterror in
your .psqlrc? Or even an /etc/psqlrc?
It would break all my scripts that must either succeed or fail -- now they
will produce garbage in my databases when something goes wrong! In my
opinion, the behaviour should depend on tty in all settings, but I am o.k.
with an AUTO setting, because so it's at least usable.
I think without tty-detection, the patch just conflicts with PostgreSQL
philosophy that the user should be kept save from unintended
data-destruction.
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.
>> * If I read the code correctly, you now don't destroy user savepoints
>> anymore, but on the other hand, you do not release the psql savepoint
>> after
>> a user-defined savepoint is released. In other words, each time a user
>> creates a savepoint, one psql savepoint is left on the subxact stack. I
>> don't know if this is a real problem, though.
>
> Correct. More detail: we release our own temporary savepoint, unless
> the user has successfully implemented their own savepoint...
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. ;-)
Best Regards,
Michael Paesold
