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  (Ferindo Middleton Jr <fmiddleton@verizon.net>)
Список 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 по дате отправления:

Предыдущее
От: Ferindo Middleton Jr
Дата:
Сообщение: redundancy in CHECK CONSTRAINTs
Следующее
От: Cere Davis
Дата:
Сообщение: Re: stored procs in postgresql