From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Oliver Jowett <oliver(at)opencloud(dot)com> |
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:34:11 |
Message-ID: | 23729.1121783651@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Oliver Jowett <oliver(at)opencloud(dot)com> writes:
> 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?
There are some, for instance someone was just complaining about this:
template1=# select 1 where 5 in (select '');
ERROR: failed to find conversion function from "unknown" to integer
My previous response was based on what was in my inbox, which I now see
wasn't the whole thread. I agree with you that if we make setString
default to UNKNOWN, there had better be a way to say "by golly this
really is TEXT" for the corner cases. It'd be a good idea if it wasn't
limited to TEXT, either, but could allow specification of any random
datatype.
I believe that UNKNOWN will work fine for 99% of cases out there,
because the backend's algorithms have been tuned for years to generally
do the right thing when presented with unadorned literal strings ---
but there has to be an escape hatch for the other 1%.
Of course, there's always the escape hatch of changing the query text,
that is write
select ... cast(? as text)
or
select ... ?::text
but this seems pretty crude.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Csaba Nagy | 2005-07-19 14:47:02 | Re: Timestamp Conversion Woes Redux |
Previous Message | Oliver Jowett | 2005-07-19 14:03:16 | Re: Timestamp Conversion Woes Redux |