Re: Timestamp Conversion Woes Redux

Tom Lane wrote:

> My previous response was based on what was in my inbox, which I now see
> wasn't the whole thread. I agree with you that if we make setString
> default to UNKNOWN, there had better be a way to say "by golly this
> really is TEXT" for the corner cases. It'd be a good idea if it wasn't
> limited to TEXT, either, but could allow specification of any random
> datatype.

We already have a mechanism for setting values of arbitary type: pass a
PGobject implementation to setObject(). We could extend this easily so
that passing a String with Types.UNKNOWN is a shorthand for passing a
PGobject with a type of 'unknown'.

It seems very odd to have a situation where the standard JDBC way of
setting a VARCHAR parameter -- setString -- sometimes doesn't work and
you have to go and use a non-standardi postgresql-specific method to say
"no, really, this *is* VARCHAR".

If we change setString() then we've gone from the existing case where
correct applications work and broken applications break, to a situation
where some correct applications do *not* work and must add this
nonstandard code to continue to work, and broken applications have the
breakage hidden.

I can understand why people want this from the perspective of supporting
existing apps that expect implicit casting of string parameters, but
from a driver-correctness and new-development perspective it seems all
wrong.

Maybe a driver URL parameter that changes the behaviour of setString()
is a reasonable compromise between the two?

-O