Re: AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards - Mailing list pgsql-hackers

From Joe Conway
Subject Re: AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards
Date
Msg-id 00e301c0f888$19839b70$0705a8c0@jecw2k1
Whole thread Raw
In response to AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards  (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>)
Responses Re: AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards
List pgsql-hackers
> > I assume you are just looking for review at this point; I would not
> > recommend applying to CVS until the BooleanTest part is done too.
> > (Since parsetree changes affect stored rules, the change really should
> > include a catversion.h increment, and thus it's best to bunch this sort
> > of change together to avoid forcing extra initdbs on other hackers.)
> > I'll look through the code later, but...
>

OK -- here's the full patch for review. It includes two new expression node
types: NullTest and BooleanTest. I have a couple of questions/comments
remaining WRT this:

-- Should I increment catversion.h as part of the patch (I didn't in this
patch), or is that usually centrally controlled by Bruce (or whomever
commits the change)?

-- IMHO, if we are going to keep the (a = null) to (a is null) conversion,
then there should also be a similar conversion from (a != null) to (a is not
null). Otherwise the two operations which may be expected to be
complimentary (as evidenced by at least one recent post) are not.

-- If I have interpreted SQL92 correctly UNKNOWN IS TRUE should return
FALSE, and UNKNOWN IS NOT TRUE is equivalent to NOT (UNKNOWN IS TRUE) ==>
TRUE. Is this correct?

Thanks,

-- Joe

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: temp-table-related failure in regression tests
Next
From: Zeugswetter Andreas SB
Date:
Subject: AW: AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. S tand ards