From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kris Jurka <books(at)ejurka(dot)com> |
Cc: | Dave Cramer <pg(at)fastcrypt(dot)com>, List <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: use of OID.Unknown |
Date: | 2005-11-08 18:52:05 |
Message-ID: | 7620.1131475925@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Kris Jurka | 2005-11-08 19:12:45 | Re: use of OID.Unknown |
Previous Message | Nicolaus.Bauman | 2005-11-08 18:46:52 | Re: use of OID.Unknown |