Re: pgsql: Add PL/pgSQL SQLSTATE and SQLERRM support
От | Tom Lane |
---|---|
Тема | Re: pgsql: Add PL/pgSQL SQLSTATE and SQLERRM support |
Дата | |
Msg-id | 23183.1117080024@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql: Add PL/pgSQL SQLSTATE and SQLERRM support (Neil Conway <neilc@samurai.com>) |
Ответы |
Re: pgsql: Add PL/pgSQL SQLSTATE and SQLERRM support
|
Список | pgsql-committers |
Neil Conway <neilc@samurai.com> writes: > Tom Lane wrote: >> Alternatively we could make them local to any block that contains an >> EXCEPTION clause, which would fix point 3 and also go a long way towards >> addressing the unnecessary-overhead gripe. However that would mean that >> an attempt to reference them from outside an exception handler would >> probably fail outright, rather than deliver either NULLs or >> 00000/"Successful completion". > This behavior sounds fine to me. I think the key distinction between this proposal and my other one (that SQLSTATE/SQLERRM be procedure-local) is whether you want the error status to be available to code that immediately follows the BEGIN block containing the exception handler. That is, consider code like BEGIN -- do something perilous EXCEPTION WHEN OTHERS THEN -- nothing much END; IF SQLSTATE = '42000' THEN ... At the moment I don't have a strong opinion about this. It seems closely analogous to the question whether a loop iteration variable should remain defined after the loop exits --- you can find cases where that's handy, but you can also argue it shouldn't be used. plpgsql itself is schizophrenic on the point (see integer versus record FOR-loops), which means we don't have a solid precedent to go by. regards, tom lane
В списке pgsql-committers по дате отправления: