Re: enhanced error fields

* Peter Geoghegan (peter(at)2ndquadrant(dot)com) wrote:
> On 28 December 2012 15:57, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > I don't think that part's been agreed to at all; it seems entirely
> > possible that it'll get dropped if/when the patch gets committed.
> > I'm not convinced that having these fields in the log is worth
> > the compatibility hit of changing the CSV column set.
>
> I am willing to let that go, because it just doesn't seem important to
> me. I just thought that if we were going to break compatibility, we
> might as well not hold back on the inclusion of fields. I'm not sure
> where this leaves the regular log. Pavel wants to remove that, too. I
> defer to others.

I'd like to see more options for what is logged, as I've mentioned in
the past, and I think all of these would be good candidates for logging
in some circumstances. The insistence on having one CSV format to rule
them all and which doesn't change (except that we've been regularly
changing it across major releases anyway..) doesn't strike me as the
right approach.

> Now, as to the question of whether we need to make sure that
> everything is always fully qualified - I respectfully disagree with
> Stephen, and maintain my position set out in the last round of
> feedback [1], which is that we don't need to fully qualify everything,
> because *for the purposes of error handling*, which is what I think we
> should care about, these fields are sufficient:

It's not entirely clear to me what distinction you're making here or if
we're simply in agreement about what the necessary fields are.
Having the schema name, table name, column name and constraint name
seems like it's sufficient to fully qualify a specific constraint..?
Where I see this being useful would be something along these lines:

COMMENT ON my_constraint ON my_schema.my_table
IS 'Please update XYZ first.';

Application runs, gets back a constraint violation, then:

SELECT
description,
consrc
FROM pg_description a
JOIN pg_constraint b ON (a.objid = b.oid)
JOIN pg_namespace c ON (b.connamespace = c.oid)
JOIN pg_class d ON (b.connrelid = d.oid)
WHERE classoid =
(select oid from pg_class x
join pg_namespace y on (x.relnamespace = y.oid)
where y.nspname = 'pg_catalog'
and x.relname = 'pg_constraint')
AND c.nspname = 'my_schema'
AND d.relname = 'my_table'
;

and have that information available to return to the client.

Thanks,

Stephen