Re: Regression: Problems with Timestamp arguments
От | Lachezar Dobrev |
---|---|
Тема | Re: Regression: Problems with Timestamp arguments |
Дата | |
Msg-id | CA+xsaB2MX7c-NeW7C_e_QcvAPCc8y03BZj4ML1GOOyeb4WwWDA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Regression: Problems with Timestamp arguments (Dave Cramer <pg@fastcrypt.com>) |
Ответы |
Re: Regression: Problems with Timestamp arguments
(Dave Cramer <pg@fastcrypt.com>)
Re: Regression: Problems with Timestamp arguments (Lachezar Dobrev <l.dobrev@gmail.com>) |
Список | pgsql-jdbc |
I (believe I) understand the issue. May I suggest a parameter to the Connection URL to specify how Timestamp is sent to the server. I am not versed enough to make a patch to hold this proposal, but if I must I will try to. How is this problem «solved» when using protocol version 2? Is there a way to degrade certain parts of the protocol? 2013/9/10 Dave Cramer <pg@fastcrypt.com>: > OK, I recall the problem here. Timestamp is rather unique in that there are > two different types of timestamps with and without timezone. > > As JDBC only has facility for one of them we have no way to say > setTimestampTZ so we allow the server to infer the type. > > There is not much that can be done without breaking a bunch of other code, > however I am open to suggestions > > Dave Cramer > > dave.cramer(at)credativ(dot)ca > http://www.credativ.ca > > > On Tue, Sep 10, 2013 at 5:57 AM, Dave Cramer <pg@fastcrypt.com> wrote: >> >> Hi, >> >> if you try this: prepare foo as select $1 is null; >> in psql you will get >> ERROR: could not determine data type of parameter $1 >> >> Why it works with integers I don't know yet, but thought I would pass that >> along >> >> Dave Cramer >> >> dave.cramer(at)credativ(dot)ca >> http://www.credativ.ca >> >> >> On Tue, Sep 10, 2013 at 5:17 AM, Lachezar Dobrev <l.dobrev@gmail.com> >> wrote: >>> >>> Hello colleagues, >>> >>> There seems to be a problem with the latest driver and Timestamp >>> arguments uses in IS NULL comparisons: >>> QUERY: SELECT ? IS NULL >>> ARGUMENTS: statement.setTimestamp(1, new >>> Timestamp(System.currentTimeMillis())) >>> >>> Result: >>> Exception in thread "main" org.postgresql.util.PSQLException: ERROR: >>> could not determine data type of parameter $1 >>> at >>> org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2157) >>> at >>> org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1886) >>> at >>> org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255) >>> at >>> org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:555) >>> at >>> org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:417) >>> at >>> org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:302) >>> >>> The problem arises on: >>> protocolVersion=3, or not specifying protocol version >>> argument type: Timestamp >>> >>> The problem does not arise on other types (tested on BigDecimal and >>> String) >>> The problem does not arise when using protocolVersion=2 >>> The problem does not arise if the expression is not ? IS NULL >>> >>> List of work-around methods: >>> - Degrade the protocol: >>> jdbc:postgresql://host:port/database?protocolVersion=2 >>> * does not work with PgPool-2 >>> >>> - Explicitly cast the argument >>> SELECT ?::timestamp IS NULL >>> SELECT CAST(? AS timestamp) IS NULL >>> * requires rewriting of currently working code >>> >>> I believe this to be a bug. >>> >>> >>> -- >>> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) >>> To make changes to your subscription: >>> http://www.postgresql.org/mailpref/pgsql-jdbc >> >> >
В списке pgsql-jdbc по дате отправления: