Excerpts from Pavel Stehule's message of mar jul 03 12:26:57 -0400 2012:
> 2012/7/2 Peter Geoghegan <peter@2ndquadrant.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.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support