* Peter Geoghegan (pe...@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
signature.asc
Description: Digital signature