>If the date is passed in binary format, it will pass it to int4recv() --
>but because the date is 4 bytes, and int4recv is defined for any 4-byte
>input, it won't cause an error; it will produce a wrong result. In other
>words, the binary representation for a date _is_ a valid binary
>representation for an integer. The type inference has found the wrong
>type, but the recv function still accepts it, which causes a problem.
Yes - of the worst kind: silent data corruption.
>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...
>Or, as Andrew suggests, you can pass the type oid along with the
>parameter so that postgresql knows the right type.
That's right - if using the binary parameters, you *must* pass an
appropriate type oid for the data you send to the server. If you use the
"unknown" oid, bad things will happen (sooner or later).
While this is strictly true of both binary and text parameters, text
parameters have enough redundancy built into the format that it's rarely
a problem. Users have come to expect this leniency.
--
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/