I don't see how it would break anything. I the case where the driver is substituting
ODBC parameters it ought to substitute (bind) the datatype that you have asked for.
In the case of "Select a_func(?,?)". If the two parameters are timestamp and smallint,
then the ODBC bind function calls specify these datatypes. Currently the ODBC
driver calls the function with a timestamp and an int4 parameter, where it should call
it with a timestamp and an int2 parameter.
I have checked a few other datatypes and looked at the "mylog" output. It seems that
dates, timestamp, numeric, floats are all explicitly typecast by the ODBC driver to
make sure the pg function gets called correctly, but not int2.
I'm not suggesting that general SQL strings are scanned and typecasts inserted.
Where functions/statements are called with parameters and those parameters then
substitued (bound) at run-time then it should get the types right where it matters.
AFAICS it is only int2 types that are not typecast. All other datatypes (except string
and int4 which don't need it) are typecast explicitly by the driver before being passed
to the server.
Regards,
Gary.
On 14 Mar 2004 at 12:30, Tom Lane wrote:
> "Gary Doades" <gpd@gpdnet.co.uk> writes:
> > I can cast inside the function, this is my current solution. Given that
> > there is no implicit downcast wouldn't the best solution be to get the
> > ODBC driver do the cast on the function call?
>
> I think that would likely fix this example at the cost of breaking many
> others. Exactly what conditions would you have the ODBC driver cast to
> int2 under?
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
