Hello
2012/12/10 Peter Geoghegan <peter@2ndquadrant.com>:
> On 10 December 2012 20:52, David Johnston <polobo@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