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

From: Thomas Lockhart <lockhart(at)fourpalms(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Joe Conway <joe(at)conway-family(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards
Date: 2001-06-08 16:27:37
Message-ID: 3B20FCF9.A8C5505A@fourpalms.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> The way things currently work is that gram.y translates "x IS TRUE" etc
> to "x = true" etc. This is wrong because it does the wrong thing for
> null input. Another objection is that it's impossible for ruleutils.c
> to reverse-list the expression tree in its original form.

fyi, in case it helps: we used to have gram.y translate these into
function calls, rather than the operator expression. But that precluded
the optimizer from ever having a shot at optimizing out "const = const"
kinds of expressions and other fluff.

If we go to a specialized node in the parse tree, then the optimizer
could be taught to handle that, which is better than the original
straight function call which would have masked things too much.

- Thomas

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message earthlink 2001-06-08 16:48:01 Internal pointers clobbered on system crash without fsync???
Previous Message Peter Eisentraut 2001-06-08 16:09:50 Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal