2012/12/29 Stephen Frost <sfr...@snowman.net>: > * Peter Geoghegan (pe...@2ndquadrant.com) wrote: >> > 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. > > I actually really like the idea of being able to programatically figure > out what constraint caused a given error and then go look up that > constraint definition and the comment associated with it, to be able to > pass back a meaningful error to the user. Reducing the cases where > users end up implementing their own application-level error checking > before sending things to the DB is a worthwhile goal, as they often end > up implementing slightly different checking that what the DB does and > get upset when the DB throws an error that they can't do anything useful > with. > >> 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. > > Perhaps we can provide a bit more help to our application developers > then by coming up with something which will work consistently- eg: we > provide the data in a structured way to the client and then a function > (or a few of them) which the application can then use to get the > details. I understand that it's complicated and I'd hope that we can do > something better. In general, I wouldn't recommend developers to query > the catalogs directly, but I don't think there's really a better option > currently. If we fix that, great. > > In the end, I may agree with you- the patch is a nice idea, but it needs > more to be a complete and working solution and providing something that > only gets people half-way there would result in developers hacking > things together which will quitely break when they least expect it.
it is a problem of this patch or not consistent constraints implementation ? Regards 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
