Re: Planning for improved versions of IN/NOT IN

Tom Lane wrote:
> Mike Mascari <mascarm@mascari.com> writes:
> 
>>I curious if any of the rewriting of EXISTS and NOT EXISTS would 
>>address the problem described by Date:

That should read "I'm curious"...

> 
> 
>>http://www.firstsql.com/iexist.htm
> 
> 
> We are not here to redefine the SQL spec ... and especially not to
> eliminate its concept of NULL, which is what Date would really like ;-)
From what I've read of Date's so far, I think he'd like to junk 
SQL altogether.

> The above-quoted screed is based on a claimed logical equivalence
> between NOT EXISTS() and NOT IN() that is just plain wrong when you
> consider the possibility of NULLs.  Rather than "FirstSQL correctly
> processes this query", you should read "FirstSQL deliberately violates
> the SQL spec".  (There may be grounds to argue that the spec behavior
> could be improved, but that's an argument to be making to the standards
> committee, not here.)

Okay. I knew there was talk in the past that IN be rewritten as 
EXISTS, which is not what you propose doing, but would have 
exposed the odd behavior NOT EXISTS exhibits according to the 
SQL spec. I was also curious to know which path PostgreSQL 
development prefers to take when the SQL spec and the Relational 
Model part ways, as they often do. Maybe someday RedHat will 
have a voting member on the ANSI X3H2/NCITS committee. ;-)

Mike Mascari
mascarm@mascari.com