Re: replacing mysql enum

From: Ian Barwick <barwick(at)gmail(dot)com>
To: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
Cc: Kenneth Gonsalves <lawgon(at)thenilgiris(dot)com>, pgsql-sql(at)postgresql(dot)org
Subject: Re: replacing mysql enum
Date: 2004-12-11 17:06:08
Message-ID: 1d581afe041211090628da57e@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

On Sat, 11 Dec 2004 07:47:51 -0800 (PST), Stephan Szabo
<sszabo(at)megazone(dot)bigpanda(dot)com> 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'))

This works as expected, although for constraints the nullness
of the column is better off handled by applying NOT NULL if
necessary.

What I still don't quite understand is why IN in a CHECK context is
handled differently to say: select 1 where 'x' in (null,'a','b','c') ?
This could be a bit of a gotcha for anyone constructing a constraint
similar to the original poster's and not realising it has no effect.

Ian Barwick

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Frank Bax 2004-12-11 17:10:02 Re: Cast NULL into Timestamp?
Previous Message Stephan Szabo 2004-12-11 16:45:19 Re: replacing mysql enum