From: | Chris Browne <cbbrowne(at)acm(dot)org> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Null and Void() - Or, Abandon All Hope Ye Who allow |
Date: | 2006-07-05 20:05:57 |
Message-ID: | 60y7v7u89m.fsf@dba2.int.libertyrms.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
gsstark(at)mit(dot)edu (Greg Stark) writes:
> Scott Marlowe <smarlowe(at)g2switchworks(dot)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(at)[local]:5432=# create table tst (as_at timestamptz);
CREATE TABLE
mn(at)[local]:5432=# insert into tst values ('infinity');
INSERT 159195836 1
mn(at)[local]:5432=# insert into tst values (now());
INSERT 159195837 1
mn(at)[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.
From | Date | Subject | |
---|---|---|---|
Next Message | Angshu Kar | 2006-07-05 20:15:02 | basic log question |
Previous Message | Bjørn T Johansen | 2006-07-05 19:51:15 | Re: Help making a plpgsql function? |