X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id B59BC3A6394 for ; Sat, 11 Dec 2004 16:45:29 +0000 (GMT) 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 79323-03 for ; Sat, 11 Dec 2004 16:45:22 +0000 (GMT) Received: from megazone.bigpanda.com (megazone.bigpanda.com [64.147.171.210]) by svr1.postgresql.org (Postfix) with ESMTP id 98F233A63F5 for ; Sat, 11 Dec 2004 16:45:21 +0000 (GMT) Received: by megazone.bigpanda.com (Postfix, from userid 1001) id 42C5835401; Sat, 11 Dec 2004 08:45:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by megazone.bigpanda.com (Postfix) with ESMTP id 414E935271; Sat, 11 Dec 2004 08:45:19 -0800 (PST) Date: Sat, 11 Dec 2004 08:45:19 -0800 (PST) From: Stephan Szabo To: Rod Taylor Cc: Ian Barwick , Kenneth Gonsalves , pgsql-sql@postgresql.org Subject: Re: replacing mysql enum In-Reply-To: <1102782901.26218.173.camel@home> Message-ID: <20041211084434.F34106@megazone.bigpanda.com> References: <04121110305520.21547@thenilgiris.com> <1d581afe04121104255557ea@mail.gmail.com> <20041211074227.J30051@megazone.bigpanda.com> <1102782901.26218.173.camel@home> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.009 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200412/62 X-Sequence-Number: 19682 On Sat, 11 Dec 2004, Rod Taylor wrote: > On Sat, 2004-12-11 at 07:47 -0800, Stephan Szabo wrote: > > On Sat, 11 Dec 2004, Ian Barwick wrote: > > > > > (Oddly enough, putting the NULL in the CHECK constraint seems > > > to make the constraint worthless: > > > test=> create table consttest (field varchar(2) check (field in > > > (null, 'a','b','c'))); > > > CREATE TABLE > > > test=> insert into consttest values ('xx'); > > > INSERT 408080 1 > > > test=> SELECT * from consttest ; > > > field > > > ------- > > > xx > > > (1 row) > > > > > > Not sure what logic is driving this). > > > > The way NULL is handled in IN (because it's effectively an equality > > comparison). Unless I miss-remember the behavior, foo in (NULL, ...) can > > never return false and constraints are satisified unless the search > > condition returns false for some row. I think this means you need the > > more verbose (field is null or field in ('a','b','c')) > > Actually, he just needs check(field in ('a', 'b', 'c')). NULL is > accepted unless explicitly denied (NOT NULL constraint or an IS NOT NULL > check). Right. For the same reason, even. Really need to stop answering messages before I wake up. :)