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