Hi, Matthew,
Matthew Bellew wrote:
> My last 2 cents on the whole topic. There is a fundamental design issue
> here with deciding to handle the expression /column <
> (value/literal/parameter typed or not)/ by converting the column to a
> string. Obviously, with INSERT INTO the data values must be coerced to
> the destination column type. In this case, while there is a
> parsing/optimizing decision to be made, it should be made with a strong
> bias to convert to the column type (and then handling any tricky
> coercion failures or optimization issues).
The problem is that you explicitly send the parameter as a String to the
server, so it gets the bias to coerce the column to the string.
However, you can always make shure the parameters are compared set
correctly by explicityl casting them:
SELECT * FROM floats WHERE x<(?::double precision);
or
SELECT * FROM floats WHERE x<CAST(? as double precision);
AFAIR, the latter one is standards conforming, and such more likely to
work on other databases.
HTH,
Markus
--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf. | Software Development GIS
Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org
