| From: | Michael Glaesemann <michael(dot)glaesemann(at)myyearbook(dot)com> |
|---|---|
| To: | Rich Shepard <rshepard(at)appl-ecosys(dot)com> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: How to handle 'not a number' in postgresql |
| Date: | 2008-01-04 15:13:16 |
| Message-ID: | 6A006968-01F4-4928-AB79-F8EA22BB6F73@myyearbook.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Jan 4, 2008, at 10:00 AM, Rich Shepard wrote:
> Maybe we have a difference in semantics that is dependent upon
> the application.
The distinction can be important, as SQL has only partially
implemented 3-valued logic (TRUE/FALSE/UNKNOWN) and treats NULL in
sometimes unexpected ways. NaN could be a useful value to distinguish
between truly unknown quantities (say, that particular machine was not
taking measurements during a particular test) and those where you've
received a value from a machine and it's NaN. But I agree, it does
depend on the application.
Michael Glaesemann
michael(dot)glaesemann(at)myyearbook(dot)com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joshua D. Drake | 2008-01-04 15:17:39 | Re: TCL |
| Previous Message | Afewtips.com | 2008-01-04 15:08:49 | Connect to SQL Server via ODBC from Postgresql |