From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | john(at)august(dot)com, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: not null - trivial, unexpected behavior |
Date: | 2001-06-17 01:23:36 |
Message-ID: | 28530.992741016@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> John Scott writes:
>> but, as i understand the sql92 standard, both att = null and att != null
>> are NOT sql92.
> They are. We just don't implement att = null right because of reasons
> that can be found in the archives.
In a very narrow sense, they're not SQL92, because SQL92 doesn't
actually allow an unadorned keyword NULL to appear in arbitrary
expression contexts. You could legally write the expression as
att = CAST (NULL AS type-of-att)
and then the required result would always be NULL, a/k/a UNKNOWN
(nb. this is NOT the same as FALSE). And indeed that's what Postgres
will produce if you do it that way.
In practice, since Postgres extends the spec to allow the unadorned
keyword NULL to appear in arbitrary expressions (with implicit
resolution of the datatype of the null), you'd expect that
att = NULL
would behave the same as if the NULL came from a CAST, evaluation of
a data value, etc. But it doesn't, for reasons that have been
discussed already.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | BORGULYA Gergely | 2001-06-17 13:24:06 | storing special characters |
Previous Message | Peter Eisentraut | 2001-06-17 00:15:01 | Re: not null - trivial, unexpected behavior |