Re: enhanced error fields

2012/12/29 Stephen Frost <sfrost@snowman.net>:
> * Peter Geoghegan (peter@2ndquadrant.com) wrote:
>> So, unless someone adds a constraint name outside of these errcodes (I
>> doubt that would make sense), there is exactly one case where a
>> constraint_name could not have a schema_name (which, as I've said, is
>> almost the same thing as constraint_schema, the exception being when
>> referencing FKs on *other* tables are involved)
>
> To be honest, I expected the concern to be about FKs and RESTRICT-type
> relationships, which I think we do need to figure out an answer for.  Is
> there a distinction between the errors thrown for violating an FK on an
> insert vs. violating a FK on a delete?  Perhaps with that we could
> identify referring table vs referred table and provide all of that
> information to the application in a structured way?
>
>> - that case is
>> ERRCODE_CHECK_VIOLATION.
>>
>> That's because this SQL could cause ERRCODE_CHECK_VIOLATION:
>>
>> select '123'::upc_barcode;
>
> I'm surprised to see that as a constraint violation rather than a domain
> violation..?  ala:
>
> =*> select '3000000000'::int;
> ERROR:  value "3000000000" is out of range for type integer
>
>> What should schema_name be set to now? Surely not the schema of the
>> type upc_barcode, since that would be inconsistent with a few other
>> ERRCODE_CHECK_VIOLATION sites where we do know schema_name +
>> table_name (those two are always either available together or not at
>> all).
>
> I'm not sure that the schema of the type would be entirely wrong in that
> specific case, along with the table name being set to the name of the
> domain.  I still think a domain violation-type error would be more
> appropriate than calling it a constraint violation though.
>
>> The bottom line is that I'm not promising that you can reliably look
>> up the constraint, and I don't think that that should be a blocker, or
>> even that it's all that important. You could do it reliably with the
>> schema_name + table_name, though I'm not strongly encouraging that you
>> do.
>>
>> So I guess we disagree on that, though I'm not *that* strongly opposed
>> to adding back in a constraint_schema field if the extra code is
>> deemed worth it.
>>
>> Does anyone else have an opinion? Tom?
>
> Having just constraint_schema and constraint_name feels horribly wrong
> as the definition of a constraint also includes a pg_class oid.

but then TABLE_NAME and TABLE_SCHEMA will be defined.

Pavel

>
>         Thanks,
>
>                 Stephen