>>>The solution is to write the query in an unambiguous way:
>>>
>>> SELECT $1::date + 1;
>>>
>>>which is good practice, anyway. If it's not obvious to the type
>>>inference system, it's probably not obvious to you, and will probably
>>>surprise you ;)
>>
>> That address this specific case, but it's ugly and not general. The right
>> thing is to set the correct type when you're marshalling the parameters...
>
>Well, ugly is in the eye of the beholder, and it certainly is a general
>solution. Any query with ambiguity in its parameters should explicitly
>declare the types, inside the query itself. Having the driver indicate
>the type should be the exception, not the rule.
You are missing the point: this is not about what types the SQL execution
sees. It is about making sure the correct recv function is applied to
the binary parameter data. The server cannot reliably infer which recv
function to use based in query context (although it tries). A wrong
guess can lead to silent data corruption, which is utterly unacceptable.
If the client (driver) sets the type OID to match the format of the
binary parameter it sends, the server can unambiguously decode the data
(and cast the type, if need be).
I would go as far as to suggest that postgres should not accept binary
parameters with an "unknown" OID - it's dangerous, unreliable and serves
no purpose.
--
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/
