Stephan Szabo <[EMAIL PROTECTED]> writes:
> That's the nature of the hack we're talking about. It's a grammar
> level hack to turn a specific sequence of tokens (= NULL) into IS
> NULL due to a client's generated queries.
Aha! Sorry -- I jumped in late in the discussion without checking
back to see how it started...
OK, I've already said that I like the cleanliness and orthogonality of
NULL is a missing data value, UNKNOWN is a missing truth value, both
propagate in expressions, comparisons with NULL generate UNKNOWN, and
you can use the special comparisons IS [NOT] NULL and IS [NOT] UNKNOWN
to get plain, two-valued Boolean truth values out of them.
The Microsoft compatibility hack is ugly, and should be either a)
removed, b) expanded to include the other comparison operators and
documented as a PostgreSQL proprietary extension, or c) made into a
special feature that's turned on at will by a SET command. I would
applaud a), approve of c), and be dismayed by b).
> I think adding IS UNKNOWN would probably be trivial (I think the
> code is basically there in IS NULL.)
But if it's implemented, shouldn't the code also differentiate between
UNKNOWN and NULL, by not (as now) using the latter to represent the
former? Or do I misunderstand how it's handled now?
-tih
--
The basic difference is this: hackers build things, crackers break them.
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
