Stephan Szabo [EMAIL PROTECTED] writes:
Given the comment on make_row_op,
/*
* XXX it's really wrong to generate a simple AND combination for =
* =. We probably need to invent a new runtime node type to handle
* those correctly. For the moment, though, keep on doing this ...
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 that
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 some
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 releases
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
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 fixed
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 = case
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.
In that
