From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
Cc: | Postgres Hackers List <hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] Re: [COMMITTERS] pgsql/src/include/parser (parse_node.h parse_oper.h) |
Date: | 1999-08-31 13:46:55 |
Message-ID: | 15225.936107215@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> writes:
>> Remove bogus code in oper_exact --- if it didn't find an exact
>> match then it tried for a self-commutative operator with the reversed input
>> data types. This is pretty silly;
> Ooh! That codes sounds familiar. What I was trying for was to cover
> the case that, for example, (int4 < float4) was not implemented, but
> that (float4 >= int4) was. If this is already handled elsewhere, or if
> this goal is nonsensical, then cutting the defective code is the right
> thing. But if the code just needed repairing, we should put it back in
> and get it right next time...
Well, what it was actually looking for was not a commuted operator but
the *same* operator name with the reversed data types; and then
demanding that this operator link to itself as its own commutator.
I don't believe such a case can ever arise in practice --- it certainly
does not now, since the opr_sanity regress test would complain if it
did.
I don't see any really good way for operator lookup to substitute
commutative operators, since it has only an operator name and not (yet)
any pg_operator entry to check the commutator link of. Surely you don't
want to hardwire in knowledge that, say, '<' and '>=' are likely to be
names of commutators.
In any case, failing to provide a full set of commutable comparison
operators will hobble the optimizer, so an implementor of a new data
type would be pretty foolish not to provide both operators. So I don't
think it's worth providing code in operator lookup to handle this
scenario.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1999-08-31 13:51:37 | Re: [HACKERS] File descriptor leakage? |
Previous Message | Tom Lane | 1999-08-31 13:36:32 | Re: [HACKERS] optimizer pruning problem |