Re: enhanced error fields

On 5 January 2013 18:06, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> I have no more new arguments for these fields - yes, there are no change

Attached revision is similar to the eelog4.diff patch (i.e. it has
only a few fields, most of which are present within the original error
message). Note that "schema_name" remains, because it was so easy to
keep it around since we pass the new infrastructure a Relation (which
also serves to sanitize). There are a few differences:

* All logging infrastructure has been removed. If the sole purpose of
this patch is to facilitate client code, it doesn't make sense to
redundantly log what is indicated by an error message. My feelings on
log-scraping tools are well known (that they shouldn't need to exist,
even if they currently do), so it won't surprise anyone to learn that
I think it's totally wrong-headed to actively facilitate them.

* Miscellaneous minor tweaks.

I think it's probably fine that we don't go into detail about how
ERRCODE_NOT_NULL_VIOLATION errors won't have a schema_name and
table_name for domains - it's obvious that they don't, because a name
cannot exist in principle. This is documented here, for example:

case DOM_CONSTRAINT_NOTNULL:
if (isnull)
+ /*
+ * We don't provide errtable here, because it is
+ * unavailable, though we require it anywhere where it is
+ * available in principle.
+ */
ereport(ERROR,
(errcode(ERRCODE_NOT_NULL_VIOLATION),
errmsg("domain %s does not allow null values",

We also go to extra lengths to get a table_name for certain
domain-related ereport sites.

So, with the question of what fields to include and whether constraint
name needs to be unambiguously resolvable addressed (I think), it
appears that I've brought this one as far as I can. I'd still like to
get input from a Perl hacker, but I think a committer needs to pick
this up now.

--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services