"Pavel Stehule" <pavel.stehule@hotmail.com> writes:
> What is problem? ANSI SQL has different model of handling exception than
> postgresql. It doesn't distinguishes between warnings and exception. Simply
> some sqlstate clases are reservated for warnings and other's for exception.
> But all sqlstate's (without '00000') can be handled via any CONTINUE, EXIT
> or UNDO handler. Exceptions are not problem.
Really? If an EXIT handler fires on a warning, does that mean the
statement giving the warning is aborted midstream, instead of being
allowed to complete?
I think that the model the SQL spec has in mind is that a warning
condition is raised only after the statement has run to completion
(which implies only one such condition per statement BTW). This is
quite at variance with our notion of WARNING. AFAICS you are not going
to be able to implement anything that works sanely if you try to take
control away at the instant of elog(WARNING). You would need to create
some infrastructure for making this happen after the statement giving
the warning is otherwise done --- which will take *much* more extensive
revisions than just hooking into elog.
regards, tom lane
