pg.ddx.io  pgsql-sql@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Richard Huxton <dev@archonet.com>
To: sad <sad@bankir.ru>
Cc: Rosser Schwarz <rosser.schwarz@gmail.com>
Cc: pgsql-sql@postgresql.org
Subject: Re: feature request ?
Date: Fri, 25 Jun 2004 09:33:30 +0100
Message-ID: <40DBE35A.70104@archonet.com> (raw)
In-Reply-To: <200406251020.41387.sad@bankir.ru>
References: <200406250816.47781.sad@bankir.ru>
	<37d451f70406242237dce4a8e@mail.gmail.com>
	<200406251020.41387.sad@bankir.ru>

sad wrote:
> On Friday 25 June 2004 09:37, Rosser Schwarz wrote:
> 
>>On Fri, 25 Jun 2004 08:16:47 +0400, sad <sad@bankir.ru> wrote:
>>
>>>>Very simply, a boolean may have to values: true or false.  It's also
>>>>possible that it's not been set to anything (NULL).
>>>
>>>really ?
>>>what about   (13 < NULL)::BOOL
>>
>>Per the semantics of NULL, 13 is neither greater than nor less than
>>NULL.  NULL is the *unknown* value; it's impossible to meaningfully
>>compare it to anything else. Try (NULL = NULL)::boolean. It's NULL,
>>also.
> 
> 
> READ THE THREAD BEFORE ANSWER

WHAT MAKES YOU THINK HE HASN'T?
OH, AND WHY ARE WE SHOUTING?

Your main argument seems to be:
  1. A boolean value may have 3 states: true/false/null
  2. The "if" statement has only if/then/else/endif
  3. The "if" statement needs to be expanded to include "elsenull" or 
similar.

Now, you can argue for/against special-casing nulls, but all other 
languages cope with defined(), isset() etc. tests.

The key point of argument, and where the problem is with your (13 < 
NULL)::BOOL point is this:
  - Boolean _values_ can have one of two states: true/false
  - Boolean _variables_ can have one of three states: true/false/null
What you had in your example was an undefined boolean variable, not a 
boolean value with a third state. You can argue that the null in 
question is of type boolean (I don't), but it is explicitly _not_ a value.

Now, your point that:
   IF (...)=true
is not the same as
   IF NOT((...)=false)
is a good one. Handling of NULLs causes a great deal of pain to 
inexperienced and experienced developers alike. You might be interested 
in the archives at http://www.dbdebunk.com/ which IIRC contains some 
articles arguing against nulls at all in a relational system.

--
   Richard Huxton
   Archonet Ltd



view thread (33+ messages)  latest in thread

Message-ID: <40DBE35A.70104@archonet.com>
Permalink:  ../40DBE35A.70104@archonet.com/
Also on:    postgresql.org/message-id/40DBE35A.70104@archonet.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-sql@postgresql.org
  Cc: dev@archonet.com, sad@bankir.ru, rosser.schwarz@gmail.com
  Subject: Re: feature request ?
  In-Reply-To: <40DBE35A.70104@archonet.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox