Re: [TCLCORE] null handling and TIP #185

[Alexandre F. <ale...@gm...>]

On Mon, Jun 16, 2008 at 4:58 PM, rna020 <tom...@fr...> wrote:
>
> SELECT * FROM A LEFT JOIN X ON A.P=X.P ;
> | P3 | A3 | B3 | NULL | NULL | NULL |

Thanks for giving this example, it is more of a concrete use case than
anything I've seen so far on the subject (I'm blaming nobody, maybe it
was obvious to distinguished SQLists, a community I'm observing from
the outside ;-).

OK, so what this means is that outer joins are a formidable supply of NULLs !
(This of course implies the complaint should not be ignored as a
purely-theoretical one; I admit I was not far from thinking so up
until now).

Now let's summarize what "we" (I mean those of us against
Null-in-the-core) propose to solve this case:

  (a) Reserve A Value:

         use an insane string constant like
"@@%%%THISISANULLBELIEVEME@@%%%"  to represent NULLs.

  (b) Encapsulate: the Maybe method

         encode NULL as [list 0 0] and everything else as [list 1 $data]

Of course, if you are the end-user of a (Tcl) wrapper of an SQL
client, this choice was most likely already made. That's why it's
being discussed on tcl-core, which focuses on enablers rather than
specific applications.

In case you're interested, a short list of pros and cons of (a) and (b):

 (a) Reserve A Value

      + full-speed access

      - creates a forbidden value ;-)
      (go find me a real example where this does any harm)

      - violates the law "not two nulls are equal"
      (important only if you iterate outer joins. I don't see a real
use for iterated non-inner joins)

  (b) Encapsulate

      + crystal-clean

      - slightly slows down access (see figures I provided)


-Alex