Re: enhanced error fields

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Peter Geoghegan <peter(at)2ndquadrant(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: enhanced error fields
Date: 2012-07-10 22:39:07
Message-ID: 8098.1341959947@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> FWIW about the new include: I feel a strong dislike about the forward
> declaration you suggest. Defining Relation in elog.h seems completely
> out of place.

Agreed. Maybe a reasonable solution is to allow some ereport helper
functions (or, really, wrappers for the helper functions) to be declared
someplace else than elog.h. They'd likely need to be implemented
someplace else than elog.c, too, so this doesn't seem unreasonable.

The generic helper function approach doesn't seem too unreasonable for
this: elog.h/.c would provide something like

err_generic_string(int fieldid, const char *str)

and then someplace else could provide functions built on this that
insert table/schema/column/constraint/etc names into suitable fields.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Farina 2012-07-10 23:02:43 Re: Synchronous Standalone Master Redoux
Previous Message Alexander Korotkov 2012-07-10 22:36:45 Re: Testing of various opclasses for ranges