Oliver Jowett <oliver@opencloud.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
