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

Re: use of OID.Unknown

From: Dave Cramer <pg(at)fastcrypt(dot)com>
To: Oliver Jowett <oliver(at)opencloud(dot)com>
Cc: List <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: use of OID.Unknown
Date: 2005-11-09 13:01:14
Message-ID: A7279DCE-82FC-4EDE-B542-3E6D27E1C7C1@fastcrypt.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
On 9-Nov-05, at 6:30 AM, Oliver Jowett wrote:

> Dave Cramer wrote:
>
>> 2) We have broken backward compatibility by changing the behaviour  
>> of  setString.
>
> My experience with the driver has been that we don't care much  
> about backwards compatibility of nonstandard behaviour between  
> major revisions -- if it's postgresql-specific code, the app can  
> just change as the driver does.
>
> That's why the protocol changes went into the 8.0 driver, but  
> weren't backported.. If your app depends on driver-specific  
> behaviour and you don't want to change it, you can keep using the  
> 7.4.x driver.

The issue here is usability, and perception. Someone on the irc  
channel was seeing a query run slower through the JDBC driver than  
through psql. I figured it had to do with using the wrong setXXX().  
It's my opinion that the driver should do the right thing from the  
users perspective, not from the specifications perspective if  
possible. If users think the driver is slower they will not use it,  
and may not use postgres. I think the option of having this behaviour  
dependent on prepareThreshold makes sense. If someone really wants to  
cache statements then I will assume they know what they are doing.
>
>> At a minimum I'd propose we bind strings to unknown.
>
> If we do this, what is the path to eventually moving away from  
> unknown? Using unknown does not feel like the right long-term  
> solution to me .. I don't want to just dig a deeper hole here.
Well, we could use the describe statement as Kris pointed out.
>
> I also agree with Tom and Kris that it seems too late to do this  
> for the "8.1" driver. Changing it in a later subrelease is the  
> wrong time to do it too -- then you'd have 7.4.x with one  
> behaviour, 8.0.x and some 8.1.x with a different behaviour, and  
> then other 8.1.x with yet another.. urgh.

I don't believe that we can leave the behaviour the way it is, so the  
sooner we can undo this the better in my opinion. There are cases  
where minor revisions of the server are quite buggy and to be avoided.
>
> (I am on leave until February, but will be infrequently checking  
> email)
Sweet, I'm jealous.
>
> -O
>
> ---------------------------(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
>


In response to

pgsql-jdbc by date

Next:From: Thomas KellererDate: 2005-11-10 00:20:13
Subject: getIndexInfo() not returning operator classes
Previous:From: Oliver JowettDate: 2005-11-09 11:30:51
Subject: Re: use of OID.Unknown

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