RE: Duplicate constraint names in 7.0.3
От | Christopher Kings-Lynne |
---|---|
Тема | RE: Duplicate constraint names in 7.0.3 |
Дата | |
Msg-id | ECEHIKNFIMMECLEBJFIGIEHGCAAA.chriskl@familyhealth.com.au обсуждение исходный текст |
Ответ на | Re: Duplicate constraint names in 7.0.3 (Stephan Szabo <sszabo@megazone23.bigpanda.com>) |
Список | pgsql-hackers |
I left it unsaid that, in fact, all constraint names should be unique. Unnamed column constraints as far as I can tell get a '$n' automatically assigned name. Maybe the create table function should process named constraints first, and then the unnamed ones to prevent such a problem? Chris -----Original Message----- From: Stephan Szabo [mailto:sszabo@megazone23.bigpanda.com] Sent: Friday, 4 May 2001 10:48 AM To: Christopher Kings-Lynne Cc: Hackers Subject: Re: [HACKERS] Duplicate constraint names in 7.0.3 If I read the spec correctly, table constraint names are supposed to be unique across a schema. So technically the constraint name should also not conflict with the name of an fk constraint, or a unique index. In addition, generated constraint names are supposed to follow the same syntax rules (which includes the uniqueness) which seems to imply that in cases like the below, that's not an error, and a different name should be generated for the unnamed constraint. However, unnamed column constraints seem to get the empty string as a name. I'd say don't worry about it for the purposes of drop constraint. :) On Fri, 4 May 2001, Christopher Kings-Lynne wrote: > Hi, > > I have noticed that it is possible to create duplicate CHECK (haven't tried > other) constraints in 7.0.3 by doing something like this: > > CREATE TABLE "test" ( > "a" int4, > CHECK (a < 400), > CONSTRAINT "$1" CHECK (a > 5) > ); > > I was just fiddling around with trying to implement the 'DROP CONSTRAINT' > code (it's quite hard - don't wait up for me!) and it would seem to be a bad > thing that it's possible to have two constraints with the same name in a > table. > > Surely there should be a UNIQUE (rcrelid, rcname) on pg_relcheck?, or at > least better checking in the CREATE TABLE code?
В списке pgsql-hackers по дате отправления: