> If we come near release time, and no one has been able to penetrate the
> index handling (to fix cases as simple as "where x = 1 + 1" which have
> never worked) the we could fairly easily go back into the parser and
> brute-force some non-general workarounds to get the few "worse than
> before" cases hacked around.
>
> If we _can_ get the index handling to work more generally, then we have
> substantially enhanced the overall capabilities of Postgres.
>
> 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...
OK, here is what I have. I have a table called test, with one
attribute. I execute:
select * from test where oid = 3;
and the output plan is:
(
{ EXPR
:typeOid 0
:opType op
:oper
{ OPER
:opno 1137
:opid 0
:opresulttype 16
}
:args (
{ VAR
:varno 1
:varattno -2
:vartype 26
:vartypmod -1
:varlevelsup 0
:varnoold 1
:varoattno -2
}
{ CONST
:consttype 23
:constlen 4
:constisnull false
:constvalue 4 [ 3 0 0 0 ]
:constbyval true
}
)
}
)
Why does the Var have a type 26(int), and the constant a type of
23(oid)? Where's the conversion function?
Now, the existance of the function doesn't help either, but that is a
different problem:
test=> explain select * from test where oid = oid(3);
NOTICE: QUERY PLAN:
Seq Scan on test (cost=1936.05 size=4916 width=8)
Is it because there is a int4eqoid() function? How to use an index on that?
--
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)
