Re: AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards

> > -- 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)?
>
> It's good to put the catversion bump into the patch, else the committer
> might forget to do it.
>
OK -- will do next time.

> further than the minimum needed to do that. The hack is fundamentally
> inconsistent anyway, and breaking our standards compliance further in
> pursuit of bogus consistency seems misguided.
>
> Personally I'd rather take out the =NULL conversion anyway...

I'd second that.

> Yes. Table 15 is pretty illegible in the ASCII draft copies of SQL92
> and SQL99, but the PDF version of SQL99 is okay, and it makes clear
> what you'd expect:
>

OT -- I need to buy a copy of SQL99, but it seems to be split into several
parts (that didn't exist for SQL92). Which one (or more) are the most useful
for PostgreSQL hacking?

> For extra credit ;-) ... if you'd like to learn a little bit about the
> optimizer, think about teaching clause_selectivity() in
> optimizer/path/clausesel.c how to estimate the selectivity of these new
> expression nodes. In the case where the argument is a boolean column
> that we have statistics for, it should be possible to derive the correct
> answer (including accounting for NULLs). If the argument is more
> complex than that, you probably can't do anything really intelligent,
> but you could handwave away NULLs and then compute the appropriate
> function of the clause_selectivity() of the argument.

Sure, I love a challenge ;) -- I'll take a look.

One issue I noticed this morning with this patch is that 't' and 'f' are no
longer being implicitly cast into boolean, i.e. test=# select 't' is true;
?column?
----------
f
(1 row)

test=# select 't'::bool is true;
?column?
----------
t
(1 row)

Any thoughts on where look to fix this?

Thanks,

-- Joe