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

Re: Timestamp Conversion Woes Redux

From: Dave Cramer <pg(at)fastcrypt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Oliver Jowett <oliver(at)opencloud(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 15:22:09
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc
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,   
>>> 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


pgsql-jdbc by date

Next:From: Dave CramerDate: 2005-07-19 15:31:24
Subject: Re: Timestamp Conversion Woes Redux
Previous:From: Deepak VohraDate: 2005-07-19 15:12:49
Subject: unsubscribe

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