Skip site navigation (1) Skip section navigation (2)

Re: enhanced error fields

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Peter Geoghegan <peter(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: enhanced error fields
Date: 2012-07-03 16:59:40
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
2012/7/3 Alvaro Herrera <alvherre(at)commandprompt(dot)com>:
> Excerpts from Pavel Stehule's message of mar jul 03 12:26:57 -0400 2012:
>> 2012/7/2 Peter Geoghegan <peter(at)2ndquadrant(dot)com>:
>> > * ereport is used so frequently that it occurs to me that it would be
>> > nice to build some error-detection code into this expansion of the
>> > mechanism, to detect incorrect use (at least on debug configurations).
>> > So maybe        constraint_relation_error() lives alongside errdetail()
>> > within elog.c. Maybe they return values of each function are some
>> > magic value, that is later  read within errfinish(int dummy,...) via
>> > varargs. From there, on debug configurations, raise a  warning if each
>> > argument is in a less than idiomatic order (so that we formalise the
>> > order).  I'm not sure if that's worth the hassle of formalising, but
>> > it's worth considering, particularly as there are calls to make our
>> > error reporting mechanism more sophisticated.
>> It is question. If I move constraint_relation_error to elog.c, then I
>> have to include utils/rel.h to utils/elog.h. It was a issue previous
>> version - criticised by Tom
> Including rel.h in elog.h is really really bad.  Even if it was only
> relcache.h it would be bad, because elog.h is included *everywhere*.
>> So current logic is - if you use "rel.h" and related structs, then you
>> can set these fields in ErrorData.
> Hm.  These new functions do not operate on Relations at all, so having
> them on relcache.c doesn't seem to me very good ...
> How about putting the functions in elog.c as Peter suggests, and the
> declarations in a new header (say relationerror.h or something like
> that)?  That new header would #include relcache.h so if you need to set
> those fields you include the new header and you have everything you
> need.

it could be


> --
> Álvaro Herrera <alvherre(at)commandprompt(dot)com>
> The PostgreSQL Company - Command Prompt, Inc.
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

pgsql-hackers by date

Next:From: Peter GeogheganDate: 2012-07-03 17:26:04
Subject: Re: enhanced error fields
Previous:From: Alvaro HerreraDate: 2012-07-03 16:48:51
Subject: Re: enhanced error fields

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group