On 8-Nov-05, at 1:52 PM, Tom Lane wrote:
> Kris Jurka <books@ejurka.com> writes:
>> I don't think this is a simple switch we should throw in a minor
>> revision
>> either. The real source of our problems is that for performance
>> reasons
>> we never issue a Describe Statement protocol message.
>
> No, I don't think that's the issue; the part that I'm worried about is
> this one:
>
>> Finally there are a few cases where the server simply cannot
>> resolve the
>> provided type and bails out with an error message. If using the JDBC
>> setXXX provided types, these work. Consider "SELECT ? IS NULL" or an
>> overloaded function that cannot be resolved.
>
> Sending UNKNOWN creates a risk that the server will barf because it
> can't guess the right data type.
>
> Now, if you are proposing to send a parameter marked UNKNOWN in
> exactly
> the same cases where the previous driver release would have sent an
> undecorated string literal, then I'm mostly OK with it --- the
> behavior
> at least won't be a regression, because an undecorated string literal
> is also taken as UNKNOWN to start with.
At this point that is what I would be advocating. It appears that
using UNKNOWN for the general
case is fraught with problems. Previously we had advocated using
setString for postgres types which do not have
jdbc counterparts such as inet, or interval. The current driver
breaks this behaviour.
>
> I remembered what it was that was nagging me about having seen this
> before --- didn't we try using UNKNOWN to avoid having to choose
> between
> timestamp with/without time zone, and didn't that idea crash and burn?
> It'd be a good idea to go back and look at the details before thinking
> of adopting UNKNOWN in a more general context.
Agreed.
>
> regards, tom lane
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>