From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
Cc: | Merlin Moncure <merlin(dot)moncure(at)rcsonline(dot)com>, gsstark(at)mit(dot)edu, pgsql-performance(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: best way to fetch next/prev record based on index |
Date: | 2004-07-28 05:53:17 |
Message-ID: | 87oem0u182.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> 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 ...
> */
> I'd expect it'd be accepted.
Hm, this code is new. As of version 1.169 2004/04/18 it only accepted "=" and
"<>" operators:
/* Combining operators other than =/<> is dubious... */
if (row_length != 1 &&
strcmp(opname, "=") != 0 &&
strcmp(opname, "<>") != 0)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("row comparison cannot use operator %s",
opname)));
I think perhaps it's a bad idea to be introducing support for standard syntax
until we can support the correct semantics. It will only mislead people and
create backwards-compatibility headaches when we fix it to work properly.
Removing <,<=,>,>= would be trivial. Patch (untested):
--- parse_expr.c.~1.174.~ 2004-07-28 01:01:12.000000000 -0400
+++ parse_expr.c 2004-07-28 01:52:29.000000000 -0400
@@ -1695,11 +1695,7 @@
*/
oprname = strVal(llast(opname));
- if ((strcmp(oprname, "=") == 0) ||
- (strcmp(oprname, "<") == 0) ||
- (strcmp(oprname, "<=") == 0) ||
- (strcmp(oprname, ">") == 0) ||
- (strcmp(oprname, ">=") == 0))
+ if (strcmp(oprname, "=") == 0)
{
boolop = AND_EXPR;
}
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.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2004-07-28 07:14:49 | Re: best way to fetch next/prev record based on index |
Previous Message | Stephan Szabo | 2004-07-28 03:45:34 | Re: best way to fetch next/prev record based on index |