> -----Original Message----- > From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers- > ow...@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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
