2012/12/28 Peter Geoghegan <pe...@2ndquadrant.com>: > On 28 December 2012 19:55, Pavel Stehule <pavel.steh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers