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

Re: use of OID.Unknown

From: Kris Jurka <books(at)ejurka(dot)com>
To: Dave Cramer <pg(at)fastcrypt(dot)com>
Cc: List <pgsql-jdbc(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: use of OID.Unknown
Date: 2005-11-08 18:36:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc

On Tue, 8 Nov 2005, Dave Cramer wrote:

> The question is still valid. This is a usability issue which will affect 
> many users who switch from 7.4 to 8.x
> I strongly suspect that the server will release a minor revision very 
> soon, which would allow us the opportunity to make this change.

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.

Right now we Parse/Bind/Describe/Execute/Sync never worrying about what 
types the 
server actually wants because we've already resolved and specified them 
from the setXXX methods (except for timestamp recently).  As you note this 
does generate some issues, especially with pg types that don't have a Java 
equivalent, for example inet.  We've also seen issues where Ken Geis was 
assuming that he could get binary results for any type.  He couldn't and 
couldn't even know that was going to happen and request binary instead 
because the s no Describe issued.

To correctly infer types we should Parse/Describe/Sync then 
Bind/Execute/Sync.  This would allow us to use the unknown oid, but still 
correctly convert provided Java types to the desired server types and in 
general would give us a lot more flexibility.  The drawback is of course 
that it'll be slower because we're doing two network trips instead of 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.

Kris Jurka

In response to


pgsql-jdbc by date

Next:From: Nicolaus.BaumanDate: 2005-11-08 18:46:52
Subject: Re: use of OID.Unknown
Previous:From: Dave CramerDate: 2005-11-08 17:43:39
Subject: Re: use of OID.Unknown

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