Greg Stark <[EMAIL PROTECTED]> writes:
> Fixing it to write out complex boolean expressions wouldn't be too hard, but
> I'm not clear it would be worth it, since I suspect the end result would be as
> the comment indicates, to introduce a new runtime node.
Just to prove that it isn't really all
> Greg Stark <[EMAIL PROTECTED]> writes:
> This approach won't get the optimizer to actually use an index for
these
> comparisons, but it will fix the semantics to match the spec. Later we
can
> either improve the optimizer to detect expressions like this (which I
> think
> would be cooler since so
Greg Stark <[EMAIL PROTECTED]> writes:
> Removing <,<=,>,>= would be trivial.
... and not backwards-compatible. If we did that then cases involving
unlabeled row expressions would no longer work as they did in prior
releases. For example
select (1,2,3) < (4,5,6);
is accepted by all rel
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Removing <,<=,>,>= would be trivial.
>
> ... and not backwards-compatible. If we did that then cases involving
> unlabeled row expressions would no longer work as they did in prior
> releases. For example
>
> select (1,2,3) < (4,5,6);
>
> is a
Tom Lane <[EMAIL PROTECTED]> writes:
> The only reason the code in parse_expr.c appears new is that the
> functionality used to be in gram.y.
Ah, that was what I was missing. Though it's odd since it seems there was code
in parse_expr.c to handle the "=" case specially.
> I'd like to see this f
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> The only reason the code in parse_expr.c appears new is that the
>> functionality used to be in gram.y.
> Ah, that was what I was missing. Though it's odd since it seems there was code
> in parse_expr.c to handle the
Tom Lane <[EMAIL PROTECTED]> writes:
> One thing I did not like about your first pass is that it makes
> unsupportable assumptions about there being a semantic relationship
> between operators named, say, '<' and '<='.
Hm, I think I even had caught that issue on the mailing list previously.
I
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> One thing I did not like about your first pass is that it makes
>> unsupportable assumptions about there being a semantic relationship
>> between operators named, say, '<' and '<='.
> In that case though, it seems e
