Mark Lewis wrote:
> It's to work around the fact that JDBC only knows about one Timestamp
> type, while PG knows about more. It ends up being better in most cases
> to send the type as unknown and let the server disambiguate to the
> correct type than to guess about the type and maybe guess wrong.
>
> This was a recent change, which is why it used to work for you but now
> doesn't. It was known that cases like yours which call overloaded
> functions may require an explicit cast, something like "SELECT
> date_trunc('day', ?::timestamp)", but it was decided that it's better to
> force a cast in some cases than to do things demonstrably wrong in other
> cases (which the older driver versions were wont to do).
>
> You can dig through the archives for more of the gory details.
>
>
Actually I am not having this problem, but I see every time people has
problems with it.
Would not it be helpful to create, say, PostgreTimestamp extends
java.sql.Timestamp and PostgreZonedTimestamp extends java.sql.Timestamp.
Then check if one uses this classes in setTimestamp/setObject and in
this case use definite bindings. And even more, return one of this types
from getTimestamp, so that some applications that do read/write will
work better even without knowing this problem.
Other application, of course, will be forced to use ::timestamp OR this
new classes explicitly. But this gives more flexibility - one would may
choose to change query text OR parameter creating and it may be much
easier in some cases to change parameter creating then sql texts.
