Re: enhanced error fields

2012/12/29 Peter Geoghegan <peter@2ndquadrant.com>:
> On 29 December 2012 17:43, Stephen Frost <sfrost@snowman.net> wrote:
>> 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.
>
> Yeah, you're probably right about that. I'm just not sure where it
> leaves this patch.
>
>> 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.
>
> I think we might be in agreement.
>
>> Having the schema name, table name, column name and constraint name
>> seems like it's sufficient to fully qualify a specific constraint..?
>
> Not necessarily, strictly speaking. It's my position that we should
> not care about the theoretical edge-cases that this presents. For
> example, I don't have any sympathy for the idea that we need to fully
> qualify that we're talking about a constraint in a particular schema,
> in case there are two distinct constraints in different schemas *that
> have the same name but don't do exactly the same thing anyway*. In
> cases where there are two distinct constraints with the same name in
> the same code path, it seems very likely that the custom error message
> to be displayed (or whatever) should not need to differ for each (this
> could come up if you were using schemas for multi-tenancy, for
> example, and each schema contained the same objects).
>
> So, in my latest revision of the patch, the only thing that isn't
> fully-qualified is constraint_name (because routine_name and so on are
> no longer included). It just seems unnecessary, given that only
> ERRCODE_CHECK_VIOLATION errors will lack a schema name and table name
> (and even then, only sometimes). Pavel originally included a
> constraint_schema field, because he figured that the way constraints
> are catalogued necessitated such a field.

Design of constraints is little bit different between ANSI SQL and
PostgreSQL. And then some fields proposed by standard has no sense in
pg - TRIGGER_SCHEMA and probably CONSTRAINT_SCHEMA. Ours constraints
are related to some relation - everywhere. You cannot create
constraint without relation - so everywhere where CONSTRAINT_NAME is
not empty, then TABLE_NAME and TABLE_SCHEMA should be defined or
CONSTRAINT_NAME should be unique in database. In my first patch used
for these field some expected generated value, but I agree, so it is
not necessary and better to drop it, although it can help with
readability of some queries.

Regards

Pavel

>
> --
> Peter Geoghegan       http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training and Services