Bruce Momjian <[EMAIL PROTECTED]> writes:
>> But that is not a shortcoming of the SET command. The problem is that the
>> system does not accept any commands after one command has failed in a
>> transaction even though it could usefully do so.
In a situation where the reason for failure was a syntax error, it seems
to me quite dangerous to try to execute any further commands; you may
not be executing what the user thought he typed. So I'm leery of any
proposals that we allow SETs to execute in transaction-abort state,
even if the implementation could support it.
> Uh, yes, we could allow the second SET to succeed even in an aborted
> transaction, but Tom says his schema stuff will not work in an aborted
> state, so Tom/I figured the only other option was rollback of the first
> SET.
The search_path case is the main reason why I'm intent on changing
the behavior of SET; without that, I'd just leave well enough alone.
Possibly some will suggest that search_path shouldn't be a SET variable
because it needs to be able to be rolled back on error. But what else
should it be? It's definitely per-session status, not persistent
database state. I don't much care for the notion of having SET act
differently for some variables than others, or requiring people to use
a different command for some variables than others.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
