Excerpts from Peter Geoghegan's message of mar jul 10 14:56:40 -0400 2012:
> On 7 July 2012 13:57, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> >> +#define PG_DIAG_TRIGGER_SCHEMA 'h'
> >>
> >> Not all appear to have a way of setting the value within the ereport
> >> interface. For example, there is nothing like "errrelation_column()"
> >> (or "errrelcol()", as I call it) to set PG_DIAG_ROUTINE_NAME. This is
> >> something I haven't touched.
> >
> > When I sent this patch first time, then one issue was new functions
> > for these fields. Tom proposal was using a generic function for these
> > new fields. These fields holds separated values, but in almost all
> > cases some combinations are used - "ROUTINE_NAME, ROUTINE_SCHEMA",
> > "TABLE_NAME, TABLE_SCHEMA" - so these fields are not independent -
> > this is difference from original ErrorData fields - so axillary
> > functions doesn't follow these fields - because it is not practical.
>
> Maybe it isn't practical to do it that way, but I think that we need
> to have a way of setting the fields from an ereport callsite. I am
> willing to accept that it may make sense to add existing ereport sites
> by piecemeal, in later patches, but I think you should figure out how
> regular ereport sites are supposed to do this before anything is
> committed. We need to nail down the interface first.
I think we should just define constants for the set of fields the patch
currently uses. When and if we later add new fields to other callsites,
we can define more constants.
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. The one you suggested as precedent (BufFile) is
completely unlike it, in that the declaration is clearly placed in the
header (buffile.h) of the module that works with the struct in question.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support