Re: use of OID.Unknown

Kris Jurka <books(at)ejurka(dot)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.

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.

regards, tom lane