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

> "Thomas G. Lockhart" <lockhart(at)alumni(dot)caltech(dot)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(at)candle(dot)pha(dot)pa(dot)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)