| From: | Greg Stark <gsstark(at)mit(dot)edu> |
|---|---|
| To: | Ian Barwick <barwick(at)gmail(dot)com> |
| Cc: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>, Kenneth Gonsalves <lawgon(at)thenilgiris(dot)com>, pgsql-sql(at)postgresql(dot)org |
| Subject: | Re: replacing mysql enum |
| Date: | 2004-12-11 17:25:50 |
| Message-ID: | 87llc44uht.fsf@stark.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-sql |
Ian Barwick <barwick(at)gmail(dot)com> writes:
> 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.
well
WHERE foo IN (null, ...)
returns null if foo isn't explicitly in the list (ie, "it may or may not equal
the unknown value in the list"). And I think constraints that return null are
deemed to have succeeded.
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2004-12-11 17:56:50 | Re: replacing mysql enum |
| Previous Message | Frank Bax | 2004-12-11 17:10:02 | Re: Cast NULL into Timestamp? |