Re: [COMMITTERS] pgsql/src/include/parser (parse_node.h parse_oper.h)

From: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
To: Tom Lane <tgl(at)hub(dot)org>
Cc: Postgres Hackers List <hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql/src/include/parser (parse_node.h parse_oper.h)
Date: 1999-08-31 05:11:06
Message-ID: 37CB63EA.376BF4E5@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Modified Files:
> parse_node.h parse_oper.h
> 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; there could never be such an operator,
> except maybe in binary-compatible-type scenarios, and we have oper_inexact
> for that. Besides which, the oprsanity regress test would complain about
> such an operator. Remove nonfunctional code and simplify routine calling
> convention accordingly.

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...

- Thomas

--
Thomas Lockhart lockhart(at)alumni(dot)caltech(dot)edu
South Pasadena, California

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Lockhart 1999-08-31 06:46:04 Re: [HACKERS] ANSI SQL compliance
Previous Message Hiroshi Inoue 1999-08-31 04:49:32 RE: [HACKERS] File descriptor leakage?