> Ah-hah, all of a sudden this looks *real* familiar. I bet it's
> because pgsql is not noticing that "500.0" can be interpreted as a
> float4. Let's try it.
Oh, you have nailed it! This is interesting because (probably) a query
like
select f4 from t4 where f4 = 500.0;
is being automatically "upgraded" in the parser backend to
select f4 from t4 where float8(f4) = 500.0;
So, since there is no functional index float8(f4) on the table we cannot
use an existing index on f4 to advantage.
This may be a result of my recent enhancements to the automatic type
coersion code. But I'm a little suprised that v6.3.x doesn't just
complain about a type mismatch but instead actually works. It may be
that the old code which converted constants using intermediate strings
worked (sort of) for this case. In general, the pre-enhancement code
_only_ tried to convert constants, and complained about type mismatches
when non-constants were involved.
So far in the examples, imho this (new?) feature isn't a _fatal_
problem, because you want to handle the following query correctly (I'll
switch to an int column to make it clearer):
select i4 from t4 where i4 < 500.1;
Now, if we do the "optimizable thing" blindly, then we would transform
this to
select i4 from t4 where i4 < int4(500.1);
But of course this would produce the wrong result if the table contains
a value of 500. Perhaps something a bit different could be implemented,
but it probably wouldn't generalize very well with the extensible type
system.
So, is there a problem to fix, or just documentation to write? I've
already written a new "Type Conversion" chapter for the User's Guide,
but haven't mentioned this specific issue.
- Tom