From: | "David Johnston" <polobo(at)yahoo(dot)com> |
---|---|
To: | "'Peter Geoghegan'" <peter(at)2ndquadrant(dot)com>, "'Pavel Stehule'" <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | "'PostgreSQL Hackers'" <pgsql-hackers(at)postgresql(dot)org>, "'Alvaro Herrera'" <alvherre(at)commandprompt(dot)com>, "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: enhanced error fields |
Date: | 2012-12-10 20:52:32 |
Message-ID: | 041101cdd718f01ae0$d4d050a0$@yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org [mailto:pgsql-hackers-
> owner(at)postgresql(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2012-12-10 20:53:42 | Re: MySQL search query is not executing in Postgres DB |
Previous Message | Simon Riggs | 2012-12-10 20:41:13 | Re: Shuffling xlog header files |