Re: [HACKERS] Re: type coersion (was OR clause status)

> "Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:
> > So far, I haven't seen cases where the parser has tried to do "the wrong
> > thing", only cases where "the right thing" causes the index handling to
> > miss the boat...
>
> I disagree, actually.  In the example
>
>     select ... where i2 = 400;
>
> I claim the parser is doing the wrong thing by representing this as
> "where int4(i2) = 400::int4" rather than "where i2 = 400::int2".
> It is not really reasonable to expect the optimizer to clean up
> after that initial mistake.

I don't see that.  If I do:

    select * from test2 where i2 = 3;

I don't see any constants being converted.  The Var is still i2, and the
Const is i4.  This is as it is seen by the optimizer.  It is using
int24eq(opno = 532).  This is valid when doing comparisons in the
executor.

The problem is how do we use indexes for this?  I am still researching
this.


---------------------------------------------------------------------------


(
   { EXPR
   :typeOid 0
   :opType op
   :oper
      { OPER
      :opno 532
      :opid 0
      :opresulttype 16
      }

   :args (
      { VAR
      :varno 1
      :varattno 1
      :vartype 21
      :vartypmod -1
      :varlevelsup 0
      :varnoold 1
      :varoattno 1
      }

       { CONST
      :consttype 23
      :constlen 4
      :constisnull false
      :constvalue  4 [  3  0  0  0 ]
      :constbyval true
      }
   )
   }
)


--
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)