Re: Timestamp Conversion Woes Redux

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Oliver Jowett <oliver(at)opencloud(dot)com>
Cc: Dave Cramer <pg(at)fastcrypt(dot)com>, Christian Cryder <c(dot)s(dot)cryder(at)gmail(dot)com>, pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Timestamp Conversion Woes Redux
Date: 2005-07-19 13:54:19
Message-ID: 23396.1121781259@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Oliver Jowett <oliver(at)opencloud(dot)com> writes:
> Dave Cramer wrote:
>> I'm also thinking we should use UNKOWN for setString as well, hopefully
>> this would reduce the number of upgrade problems people are having when
>> they upgrade from 7.x to 8.x

> I still think this is a bad idea.

I think one main point against using UNKNOWN is that it creates a risk
of "could not resolve parameter type" query failures. That's OK for
generic setString() cases, since the user can always escape the failure
by changing his code to specify the parameter type more clearly.

The other argument against UNKNOWN is that the backend might choose an
unexpected data type. Again, that doesn't scare me a lot for setString,
because the backend's rules for dealing with UNKNOWN are biased in favor
of resolving the parameter type as TEXT, which seems perfectly
reasonable for setString cases.

Unfortunately, both of these considerations speak *against* using
UNKNOWN for Timestamp. If the backend rejects the query --- or more
likely, makes the wrong datatype choice --- there will be no way for
the user to fix it.

So I'm in favor of using UNKNOWN for setString, but I think we gotta
find another answer for Christian's problem.

regards, tom lane

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Oliver Jowett 2005-07-19 14:03:16 Re: Timestamp Conversion Woes Redux
Previous Message Oliver Jowett 2005-07-19 13:22:11 Re: Timestamp Conversion Woes Redux