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

"Joe Conway" <joseph.conway@home.com> writes:
> 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?

I find that Part 2 is almost the only one I ever look at.  I'm not even
sure what's in the other parts ...

> 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)

Now that you mention it, it looks like all of our constructs that expect
boolean fail to coerce unknown-type literals into bools.  The rest of
them raise errors, eg:
regression=# select not 't';ERROR:  argument to NOT is type 'unknown', not 'bool'

but this is pretty bogus.  ISTM all these places should try to coerce
their inputs to bool before they complain.  This involves calling
can_coerce_type and then coerce_type; it's tedious enough that it'd be
worth setting up a subroutine to do it.  I'll add something for that,
and fix the other places too.
        regards, tom lane