Re: redundancy in CHECK CONSTRAINTs
От | Tom Lane |
---|---|
Тема | Re: redundancy in CHECK CONSTRAINTs |
Дата | |
Msg-id | 26530.1127620701@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | redundancy in CHECK CONSTRAINTs (Ferindo Middleton Jr <fmiddleton@verizon.net>) |
Ответы |
Re: redundancy in CHECK CONSTRAINTs
|
Список | pgsql-sql |
Ferindo Middleton Jr <fmiddleton@verizon.net> writes: > I have the following table: > CREATE TABLE gyuktnine ( > id SERIAL, > intsystem INTEGER NOT NULL REFERENCES yuksystems(id) CONSTRAINT > int_cannot_equal_ext > CHECK (intsystem != extsystem), > extsystem INTEGER NOT NULL REFERENCES yuksystems(id) CONSTRAINT > ext_cannot_equal_int > CHECK (extsystem != intsystem), > PRIMARY KEY (intsystem, extsystem) > ); > Is this redundant? Yes. I think it's poor style too: a constraint referencing multiple columns should be written as a table constraint not a column constraint. That is, you ought to write CREATE TABLE gyuktnine ( id SERIAL, intsystem INTEGER NOT NULL REFERENCES yuksystems(id), extsystem INTEGER NOT NULL REFERENCES yuksystems(id), PRIMARY KEY (intsystem, extsystem), CONSTRAINT int_cannot_equal_extCHECK (intsystem != extsystem) ); At least in the earlier versions of the SQL standard, it was actually illegal for a column constraint to reference any other columns. I'm not sure if that's still true in the latest spec. Postgres treats column constraints and table constraints alike, but other SQL databases are likely to be pickier. BTW, is there any actual need for the "id" column here, seeing that you have a natural primary key? regards, tom lane
В списке pgsql-sql по дате отправления: