What about creating two extension classes
PGTimestamp, and PGTimestamptz
then allowing setObject to recognize these internally and bind to
Oid.Timestamp, and Oid.Timestamptz repectively
for setString I am in favour of using UNKNOWN as this is no worse
than what 7.4 drivers do now
On 19-Jul-05, at 9:54 AM, Tom Lane wrote:
> Oliver Jowett <oliver(at)opencloud(dot)com> writes:
>> Dave Cramer wrote:
>>> I'm also thinking we should use UNKOWN for setString as well,
>>> 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
> 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
> because the backend's rules for dealing with UNKNOWN are biased in
> 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
pgsql-jdbc by date
|Next:||From: Dave Cramer||Date: 2005-07-19 15:31:24|
|Subject: Re: Timestamp Conversion Woes Redux|
|Previous:||From: Deepak Vohra||Date: 2005-07-19 15:12:49|