Re: Timestamp Conversion Woes Redux

Oliver Jowett <oliver@opencloud.com> writes:
> Dave Cramer wrote:
>> I'm also thinking we should use UNKOWN for setString as well,  hopefully
>> this would reduce the number of upgrade problems people are  having when
>> they upgrade from 7.x to 8.x

> I still think this is a bad idea.

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.

Unfortunately, both of these considerations speak *against* using
UNKNOWN for Timestamp.  If the backend rejects the query --- or more
likely, makes the wrong datatype choice --- there will be no way for
the user to fix it.

So I'm in favor of using UNKNOWN for setString, but I think we gotta
find another answer for Christian's problem.

            regards, tom lane