Horton

Re: enhanced error fields

Peter Geoghegan <peter@2ndquadrant.com>

View thread
From: Peter Geoghegan <peter@2ndquadrant.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Pavel Stehule <pavel.stehule@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Alvaro Herrera <alvherre@commandprompt.com>
Date: 2012-12-29T20:18:07Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Create a "sort support" interface API for faster sorting.

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