Re: NULLs: theoretical problems?

From: -CELKO- <jcelko212_at_earthlink.net>
Date: Mon, 13 Aug 2007 06:27:08 -0700
Message-ID: <1187011628.630387.262960_at_19g2000hsx.googlegroups.com>


>> Meaning

 CREATE VIEW Foobar (a INTEGER, b REAL, c DATE)  AS
 VALUES (NULL, NULL, NULL); <<

Not quite. A VIEW is not a direct table declaration as you are trying to show with your invented notation. I can do UNIONs, JOINs, etc. or pretty much any query in the body. The VIEW header is more like a multi-column version of AS clauses.

I think you missed the part about VALUES being a row or table constructor and think of it as an input list; wrong mindset!

>> I'm not sure the former should even be allowed, and you would only
think of it if you assumed that NULL was a value - as you might have gathered, my opinion is that it is not. <<

I happen to agree that NULL is a marker and not a value; but the fiction in SQL for implementations is that it is a "special value" like the NaN ("Not a Number") in IEEE floating point -- I think some VLDB SQLs actually use the NaN for a NULL in REAL, FLOAT and DOUBLE PRECISION data types so that their heavy statistical work can be done with a math co-processor.

But the VIEW..VALUES() is a great feature. It lets you define table constants that cannot be altered, just like the CONSTANT declarations in procedural languages. Received on Mon Aug 13 2007 - 15:27:08 CEST

Original text of this message