Re: Timestamp Conversion Woes Redux

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

Dave
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
>
>