Skip site navigation (1) Skip section navigation (2)

Re: use of OID.Unknown

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 (view raw or flat)
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

In response to

Responses

pgsql-jdbc by date

Next:From: Kris JurkaDate: 2005-11-08 19:12:45
Subject: Re: use of OID.Unknown
Previous:From: Nicolaus.BaumanDate: 2005-11-08 18:46:52
Subject: Re: use of OID.Unknown

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group