Re: redundancy in CHECK CONSTRAINTs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: fmiddleton(at)verizon(dot)net
Cc: pgsql-sql(at)postgresql(dot)org
Subject: Re: redundancy in CHECK CONSTRAINTs
Date: 2005-09-25 03:58:21
Message-ID: 26530.1127620701@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Ferindo Middleton Jr <fmiddleton(at)verizon(dot)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_ext CHECK (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

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Cere Davis 2005-09-25 04:10:48 Re: stored procs in postgresql
Previous Message Ferindo Middleton Jr 2005-09-25 03:34:15 redundancy in CHECK CONSTRAINTs