Re: use of OID.Unknown

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
>