2012/12/28 Peter Geoghegan <peter@2ndquadrant.com>:
> On 28 December 2012 19:55, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>> http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Fdb2%2Frbafzmstgetdiag.htm
>
> I'm unconvinced by this. First of all, it only applies to the GET
> DIAGNOSTICS statement, and the only implementation that actually
> currently uses that is DB2, AFAICT. Secondly, DB2 only provides it for
> very specific errcode classes that relate to problems that are
> peculiar to routines/functions, so in general you cannot rely on the
> information being available in the same way as you intend. Clearly,
> DB2 provides it for completeness, and not because you can rely on it
> being available for error handling purposes. On the other hand, your
> latest revision of the patch (eelog5.patch) sees plpgsql jury-rigged
> to set the fields itself, which seems like a whole other proposition
> entirely.
>
> What's more, you're changing ErrorData to make this happen, rather
> than having the user interrogate the server for this information as
> GET DIAGNOSTICS does. So I don't see that this supports your case at
> all. I maintain that having an exception handler's behaviour vary
> based on a field that describes a routine that originally raised the
> function is a really bad idea, and that we should not facilitate it.
It cannot to wait to GET DIAGNOSTICS request - because when GET
DIAGNOSTICS is called, then all unsupported info about exception is
lost, all used memory will be released. So if we would to support
ROUTINE_NAME or similar fields like CONTEXT or MESSAGE, we have to
store these values to ErrorData without knowledge if this value will
be used or not.
Pavel
>
> --
> Peter Geoghegan http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training and Services