2012/7/3 Alvaro Herrera <alvhe...@commandprompt.com>: > > Excerpts from Pavel Stehule's message of mar jul 03 12:26:57 -0400 2012: > >> 2012/7/2 Peter Geoghegan <pe...@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. >
it could be Pavel > -- > Álvaro Herrera <alvhe...@commandprompt.com> > The PostgreSQL Company - Command Prompt, Inc. > PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers