Re: replacing mysql enum
От
Stephan Szabo
Тема
Re: replacing mysql enum
Дата
Msg-id
20041211074227.J30051@megazone.bigpanda.com
Ответ на
Re: replacing mysql enum (Ian Barwick)
Список
Дерево обсуждения
replacing mysql enum Kenneth Gonsalves <lawgon@thenilgiris.com>
Re: replacing mysql enum Ian Barwick <barwick@gmail.com>
Re: replacing mysql enum Tom Lane <tgl@sss.pgh.pa.us>
Re: replacing mysql enum Stephan Szabo <sszabo@megazone.bigpanda.com>
Re: replacing mysql enum Rod Taylor <pg@rbt.ca>
Re: replacing mysql enum Stephan Szabo <sszabo@megazone.bigpanda.com>
Re: replacing mysql enum Ian Barwick <barwick@gmail.com>
Re: replacing mysql enum Greg Stark <gsstark@mit.edu>
Re: replacing mysql enum Josh Berkus <josh@agliodbs.com>
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'))
В списке pgsql-sql по дате отправления
От: tomas@nocrew.org (Tomas Skäre)
Дата: