On 29 December 2012 19:56, Stephen Frost <sfrost@snowman.net> wrote:
>> - 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..?
I was trying to convey that upc_barcode is a domain with a check
constraint (i.e. that the checkdigit on UPC barcode domains must be
correct). So yes, that would be an ERRCODE_CHECK_VIOLATION. See
ExecEvalCoerceToDomain().
>> 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.
Well, it is what it is. We can't change it now.
> Having just constraint_schema and constraint_name feels horribly wrong
> as the definition of a constraint also includes a pg_class oid.
I think that it's probably sufficient *for error handling purposes*.
Since it is non-trivial to get the schema of a constraint, and since
we have that jarring inconsistency (the schema of the type or the
schema of the table on which a check constraint is defined?) we might
well be better off just not addressing it.
It isn't as simple as you make out. Not all constraints appear within
pg_constraint (consider NOT NULL constraints), and besides,
pg_constraint.conrelid can be zero for non-table constraints. What's
more, pg_constraint actually has three pg_class oid columns; conrelid,
conindid and confrelid.
That is all.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services