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. -- 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
