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

Re: Timestamp Conversion Woes Redux

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 14:03:16
Message-ID: 42DD0824.9060002@opencloud.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
Tom Lane wrote:

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

The main thing I'm worried about there is that if there are cases where 
an UNKNOWN parameter will generate an error rather than resolve to TEXT, 
then the driver has just backed the user into a corner they can't escape 
from. Are there any cases where this can happen? (I'm thinking of some 
of the ambiguous-type problems we ran into when sending nulls as UNKNOWN..)

-O

In response to

Responses

pgsql-jdbc by date

Next:From: Tom LaneDate: 2005-07-19 14:34:11
Subject: Re: Timestamp Conversion Woes Redux
Previous:From: Tom LaneDate: 2005-07-19 13:54:19
Subject: Re: Timestamp Conversion Woes Redux

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