gsstark@mit.edu (Greg Stark) writes:
> Scott Marlowe <smarlowe@g2switchworks.com> writes:
>
>> However, there are often nulls that fall in the category of "who
>> cares?" For those, null is a perfectly acceptable alternative, and
>> there's no need for all the extra work.
>
> There is often a need for special case values. Situations like "subscription
> expiration date" for a subscription that shouldn't expire at all, or even
> "income level" for users who refuse to give that information. Also for things
> like the various NaN values.
>
> I kind of wish SQL allowed for an arbitrary set of "special values" regardless
> of data type rather than allow a single special value and have so many hard
> coded magical behaviours.
In the case of "never expires," there is a well-defined "infinity" value...
mn@[local]:5432=# create table tst (as_at timestamptz);
CREATE TABLE
mn@[local]:5432=# insert into tst values ('infinity');
INSERT 159195836 1
mn@[local]:5432=# insert into tst values (now());
INSERT 159195837 1
mn@[local]:5432=# select * from tst;
as_at
-------------------------------
infinity
2006-07-05 19:35:01.233889+00
(2 rows)
As for having larger numbers of "not there" values, that tends to have
somewhat unfortunate effects on system logic, as code needs to be
aware of additional "special values."
--
output = reverse("gro.mca" "@" "enworbbc")
http://cbbrowne.com/info/emacs.html
"Of course 5 years from now that will be different, but 5 years from
now everyone will be running free GNU on their 200 MIPS, 64M
SPARCstation-5." -- Andrew Tanenbaum, 1992.