On Jun 8, 2006, at 9:32 PM, David Fetter wrote:
On Thu, Jun 08, 2006 at 06:09:21PM -0700, Trent Shipley wrote:
On Thursday 2006-06-08 15:14, David Fetter wrote:
On Thu, Jun 08, 2006 at 05:21:07AM -0700, [EMAIL PROTECTED] wrote:
on bag theory[1] and 3-value logic[2]. Until they come up with a
testable system, or Hell freezes over, whichever comes first,
Pascal's book will make a good companion on your shelf to books on
Phlogiston[3] theory, or a decent doorstop, whichever you prefer.
I have encountered at least two commercial database products that
declared every column "NOT NULL". I have always assumed that this
was defensive, preventing stupid programmer mistakes.
It's not that simple. If there are no NULLs allowed anywhere, that
means that you can't even have them as the output of a SELECT
statement, which means no OUTER JOINs. No repetitions means none
anywhere, which means that they can't be the output of a query either,
and makes it complicated at best to do aggregates. The whole thing is
just ridiculous on its face.
Yes, no repetition. The point is that all functions should return
actual relations, so no ordering either. This makes it trivial to chain
the operations which is painful to do in SQL because you have to pay
attention to return types *and* whether or not the subquery returns one
or more rows or just one "value".
The OUTER JOIN stuff is a limitation of SQL. In the relational model,
there is no reason a column type cannot be a relation itself, however
SQL can't cope well with that. Aggregates can return relations as
header types so all the applicable tuples are returned. I have to do
that in PostgreSQL with arrays but there is no trivial way to convert
between arrays and a fake view or table or a VALUES() construct :-(
¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬
AgentM
[EMAIL PROTECTED]
¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
