Re: [subxacts] Aborting a function - Mailing list pgsql-hackers

On 07/10/04:27/6, Tom Lane wrote:
> Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> > (We could talk about exception support in plpgsql or other language
> > handlers but I don't think this is going to happen for 7.5.)
>
> Au contraire ... I think it *must* happen, and indeed that
> subtransaction support in plpgsql is not different from exceptions.
> Per Honza Pazdziora's recent post:
>
> >> The syntax of handling exceptions is (in PL/SQL):
> >>
> >>     BEGIN
> >>         some code, for example a bunch of SQL commands;
> >>     EXCEPTION
> >>         WHEN nameofexception THEN
> >>             handle the exception, maybe ROLLBACK;
> >>     END;

Shortly, does that snippet imply that an extension author will have the
ability to catch and "resolve" ERRORs, and have access to the error data?


[I was planning on bringing this up at a later time, but this thread seems
directly related to a feature that I would like plpy to have.]

Does the above snippet mean what I think it means? That is, will one be able to
trap ERRORs without being required to raise it like one would do now
--siglongjmp'ing Warn_restart, and such. Will one have access to the currently
static ErrorData in elog.c? This would seem necessary if one is going to
be able to test anything about exception that occurred('nameofexception').
This is what I would hope from looking at the above snippet of PL/PgSQL code,
but I hope such a feature would be available independent of subxacts(tho, not
within the context of a PL/PgSQL procedure, I suppose).

Putting it in the context of PL/Py:

try:   r = Postgres.Relation("primary_source")
except Postgres.Error:   r = someOtherObjectTheProvidesTheNecessaryInfoWithACompatibleInterface
#          ---  or, perhaps  ---   raise MyDBAppException(       "More appropriate error message than 'failed to
openprimary_source', with description about how to resolve error       specific the DB application/template a user
mightbe using",       detail="some good details"       hint="a good hint"   ) 
...

In Python it is quite common to do something like that, rather than testing
ahead of the action.

I've whined about this a couple times on #postgresql, both times the responses
raised the same good question, "What would you do with the error when you get
it?". I think that the best response to that is that depends on the user's
application, and the context of his/her usage.

It should also be noted that I have, with _apparent_ success, caught an
ERROR, and continued on my merry way without raising it. To say the
least, it was done without elegance as the client is likely to get
the ERROR message from errstart. That and the fact that I cannot access the
static ErrorData is what kept me from keeping that functionality.
(I basically stored and restored the state of a couple globals which may have
been changed by an elog(ERROR), ie, InError)

--
Regards,       James William Pye