> "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)
