Re: set constraints docs page
От | Kevin Brown |
---|---|
Тема | Re: set constraints docs page |
Дата | |
Msg-id | 20030819211830.GK16911@filer обсуждение исходный текст |
Ответ на | Re: set constraints docs page (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: set constraints docs page
|
Список | pgsql-hackers |
Tom Lane wrote: > "Andrew Dunstan" <andrew@dunslane.net> writes: > >> I object to creating gratuitous incompatibilities with the SQL standard, > >> which will obstruct legitimate features down the road. The SQL standard > >> says it is <schema>.<constraint>. > > > Is there a case for enforcing uniqueness on constraint names, then? > > Other than "SQL92 says so"? Very little. This seems to me to be a > design error in the spec. Per-table constraint names are easier to > work with --- if they're global across a schema then you have a serious > problem avoiding collisions. I assume that SQL99 and later don't specify anything different than what SQL92 calls for in this regard? Without any meaningful guidance from the spec, the best we can do is support per-table constraint names and provide optional (via a GUC variable) support for SQL92-compliant constraint names. Let the DBA decide which (if not both) is best for his situation. Inasmuch as one of our "selling points" is our compliance with the SQL spec, I see little reason to entirely avoid compliance with the spec on this issue -- just make it possible to do something else when/if necessary. 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. -- Kevin Brown kevin@sysexperts.com
В списке pgsql-hackers по дате отправления: