Re: Timestamp Conversion Woes Redux

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

In response to

Responses

Browse pgsql-jdbc by date

  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