2012/12/29 Stephen Frost <sfr...@snowman.net>: > * 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.
but then TABLE_NAME and TABLE_SCHEMA will be defined. Pavel > > Thanks, > > Stephen -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
