Re: set constraints docs page - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: set constraints docs page |
Date | |
Msg-id | 200309050050.h850oJJ20926@candle.pha.pa.us Whole thread Raw |
In response to | Re: set constraints docs page (Kevin Brown <kevin@sysexperts.com>) |
Responses |
Re: set constraints docs page
(Kevin Brown <kevin@sysexperts.com>)
|
List | pgsql-hackers |
Kevin Brown wrote: > Bruce Momjian wrote: > > Kevin Brown wrote: > > > The two approaches aren't necessarily mutually exclusive (though SQL99 > > > compliance on constraint names would obviously make it unnecessary to > > > specify a tablename along with a constraint name), so I see little > > > problem here. But the current arrangement is obviously untenable, > > > because it allows you to create a situation (multiple constraints by > > > the same name) that you can't reasonably extricate yourself from. > > > > Well, it seems if we want to continue to allow the same constraint name > > to be used by different tables in the same schema, we have to print the > > tablename in the error message. Would someone actually be looking for a > > standards-compliant error string? We have already extended the standard > > --- either we revert that, or we have to go the entire way and print the > > table name. > > If PG were configurable in terms of how it manages constraint names, > then it would depend on how the DBA had the database configured. With it > configured to disallow name collisions, it would obviously be unnecessary > to report the table name, though I still think it would be useful (if > only because it gives a little extra context to work with). But if it's > configured to allow name collisions, then it doesn't make sense not to > print the table name in an error message, because that's the only way to > guarantee that the DBA can identify which constraint is being referred to. > > > The problem as things stand now is that even if we printed the table name > involved, the DBA is placed in a difficult position if the constraint in > question isn't uniquely named -- which is the only case where printing > the table name would really matter. That's because he can't actually > refer to the constraint in any unique way short of playing with the > system tables; he'd have to rename the constraint first before being > able to really do something with it (is this even possible for him to > do without manipulating system tables? Is there an ALTER CONSTRAINT?). Added to TODO: * Print table names with constraint names in error messages, or make constraint names unique within a schema -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
pgsql-hackers by date: