| 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 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2005-07-19 14:34:11 | Re: Timestamp Conversion Woes Redux |
| Previous Message | Tom Lane | 2005-07-19 13:54:19 | Re: Timestamp Conversion Woes Redux |