> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers-
> owner@postgresql.org] On Behalf Of Peter Geoghegan
> Sent: Monday, December 10, 2012 3:29 PM
> To: Pavel Stehule
> Cc: PostgreSQL Hackers; Alvaro Herrera; Tom Lane
> Subject: Re: [HACKERS] enhanced error fields
>
> Now, there are one or two places where these fields are not actually
> available even though they're formally required according to a literal
reading
> of the above. This is only because there is clearly no such field sensibly
> available, even in principle - to my mind this cannot be a problem,
because
> the application developer cannot have any reasonable expectation of a
field
> being set. I'm really talking about two cases in particular:
>
> * For ERRCODE_NOT_NULL_VIOLATION, we don't actually provide
> schema_name and table_name in the event of domains. This was previously
> identified as an issue. If it is judged better to not have any
requirements
> there at all, so be it.
>
> * For the validateDomainConstraint() ERRCODE_CHECK_VIOLATION ereport
> call, we may not provide a constraint name iff a Constraint.connname is
> NULL. Since there isn't a constraint name to give even in principle, and
this is
> an isolated case, this seems reasonable.
>
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%?
From an "ease-of-use" aspect for the API if I can simply always query each
of those fields and know I will be receiving a string it does at least seem
theoretically easier to interface with. If I am expecting special string
values (enclosed in symbols making them invalid identifiers) I can then
handle those as desired without either receiving an error or a NULL when I
go to poll the missing field if those couple of instances.
I may be paranoid or mistaken regarding how this work but figured I'd at
least throw it out for consideration.
David J.