Re: Timestamp Conversion Woes Redux

Hi all,

My opinion as a user who just "fixed" his application to properly set
the data base types: fixing the application is a bigger PITA than fixing
weird cases of strange type choices of the server. The first one
involves changing lots of exiting code, the second involves newly
written code, as I think the old code relying on setting string and
letting the server decide what is it should work fine.
In my case I've had to make extra meta data look-ups to be able to
properly set the data type in some of our more generic code, which is
adding some complexity overhead to my code (I presume the performance
difference is negligible). Given the fact that the server is very likely
to decide correctly the type, and a lot of code can be simpler if no
exact knowledge of the data types is needed, I think setting the type to
unknown should be acceptable.
Actually, will this allow to use setString on a boolean field using
preaparedStatements ? 'cause that's the one which gave me the headaches.

Just my 2c.

Cheers,
Csaba.

On Tue, 2005-07-19 at 16:03, Oliver Jowett wrote:
> 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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend