X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id EB990D7336 for ; Sun, 25 Sep 2005 01:46:20 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 81199-01 for ; Sun, 25 Sep 2005 04:46:15 +0000 (GMT) Received: from vms042pub.verizon.net (vms042pub.verizon.net [206.46.252.42]) by svr1.postgresql.org (Postfix) with ESMTP id 2E5B9D9527 for ; Sun, 25 Sep 2005 01:46:12 -0300 (ADT) Received: from [192.168.1.11] ([68.239.68.205]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0INC00JH9VWFN4D3@vms042.mailsrvcs.net> for pgsql-sql@postgresql.org; Sat, 24 Sep 2005 23:46:12 -0500 (CDT) Date: Sun, 25 Sep 2005 00:46:52 -0400 From: Ferindo Middleton Jr Subject: Re: redundancy in CHECK CONSTRAINTs In-reply-to: <26530.1127620701@sss.pgh.pa.us> To: Tom Lane Cc: pgsql-sql@postgresql.org Reply-To: fmiddleton@verizon.net Message-id: <43362BBC.1050301@verizon.net> Organization: Sleek Collar MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <43361AB7.2020701@verizon.net> <26530.1127620701@sss.pgh.pa.us> User-Agent: Thunderbird 1.4 (Windows/20050908) X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=1.375 required=5 tests=[AWL=-0.375, DNS_FROM_RFC_ABUSE=0.374, DNS_FROM_RFC_POST=1.376] X-Spam-Level: * X-Archive-Number: 200509/248 X-Sequence-Number: 22795 Thank you for your advice, Tom. I've re-done the table in my db using the schema you describe below. The is a need for the id field. Other tables in my applications use it to refer to any one intsystem/extsystem relationship and be able to provide users with one simple number to use to refer to them. Thank you. Ferindo Tom Lane wrote: > Ferindo Middleton Jr 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 > >