Re: enhanced error fields

* 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.
Thanks,
    Stephen