Hello 2012/12/10 Peter Geoghegan <pe...@2ndquadrant.com>: > On 10 December 2012 20:52, David Johnston <pol...@yahoo.com> wrote: >> Just skimming this topic but if these enhanced error fields are going to be >> used by software, and we have 99% adherence to a standard, then my first >> reaction is why not just supply "<Not Applicable>" (or "<Not Available>" as >> appropriate) instead of suppressing the field altogether in these (and >> possibly other, future) cases and make adherence for these fields 100%? > > Well, this is an area that the standard doesn't have anything to say > about. The standard defines errcodes, but not what fields they make > available. I suppose you could say that the patch proposes that they > become a Postgres extension to the standard.
standard speaking relative cleanly about content of diagnostics fields - it should to be empty string or value. We don't know what and how to be filled from standards, but we know, so "<Not Applicable>" or some similar is not compatible with ANSI SQL Regards Pavel > > I probably could have found more places to set the fields. Certainly, > I've already set them in some places where they are not actually > required to be set by the new contract of errcodes.txt/errcodes.h. My > immediate concern is getting something minimal committed, though. I > think the latest revision handles all of the important cases (i.e. > cases where applications may want a well-principled way of detecting a > particular kind of error, like an error due to the violation of a > particular, known constraint). > > -- > 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
