Re: The same prepared query yield "-1" the first six times and then "-1.0" - Mailing list pgsql-general
From | Dave Cramer |
---|---|
Subject | Re: The same prepared query yield "-1" the first six times and then "-1.0" |
Date | |
Msg-id | CADK3HHJ-ejxz-ODpAFh4w1zgzznEmWbMjknUm90xgeLHnet1Lg@mail.gmail.com Whole thread Raw |
In response to | Re: The same prepared query yield "-1" the first six times and then "-1.0" (Edoardo Panfili <edoardopa@gmail.com>) |
List | pgsql-general |
On Tue, 22 Aug 2023 at 01:54, Edoardo Panfili <edoardopa@gmail.com> wrote:
And I expected to obtain the same from the JDBC connectionIl giorno 21 ago 2023, alle ore 21:37, Dave Cramer <davecramer@postgres.rocks> ha scritto:On Mon, 21 Aug 2023 at 14:42, Edoardo Panfili <edoardopa@gmail.com> wrote:
> Il giorno 21 ago 2023, alle ore 20:13, Peter J. Holzer <hjp-pgsql@hjp.at> ha scritto:
>
> On 2023-08-21 17:27:20 +0200, Edoardo Panfili wrote:
>> The attended result was a sequence of ten equal values but this is the actual result:
>> p: -1
>> p: -1
>> p: -1
>> p: -1
>> p: -1
>> p: -1.0
>> p: -1.0
>> p: -1.0
>> p: -1.0
>> p: -1.0
> [...]
>> 2023-08-21 11:51:50.633 CEST [1511] user@testdb LOG: execute <unnamed>: SET extra_float_digits = 3
>> 2023-08-21 11:51:50.634 CEST [1511] user@testdb LOG: execute <unnamed>: SET application_name = 'PostgreSQL JDBC Driver'
>> 2023-08-21 11:51:50.644 CEST [1511] user@testdb LOG: execute <unnamed>: SELECT dim1 FROM number WHERE name='first'
>> 2023-08-21 11:51:50.648 CEST [1511] user@testdb LOG: execute <unnamed>: SELECT dim1 FROM number WHERE name='first'
>> 2023-08-21 11:51:50.649 CEST [1511] user@testdb LOG: execute <unnamed>: SELECT dim1 FROM number WHERE name='first'
>> 2023-08-21 11:51:50.650 CEST [1511] user@testdb LOG: execute <unnamed>: SELECT dim1 FROM number WHERE name='first'
>> 2023-08-21 11:51:50.651 CEST [1511] user@testdb LOG: execute S_1: SELECT dim1 FROM number WHERE name='first'
>> 2023-08-21 11:51:50.651 CEST [1511] user@testdb LOG: execute S_1: SELECT dim1 FROM number WHERE name='first'
>> 2023-08-21 11:51:50.653 CEST [1511] user@testdb LOG: execute S_1: SELECT dim1 FROM number WHERE name='first'
>> 2023-08-21 11:51:50.653 CEST [1511] user@testdb LOG: execute S_1: SELECT dim1 FROM number WHERE name='first'
>> 2023-08-21 11:51:50.654 CEST [1511] user@testdb LOG: execute S_1: SELECT dim1 FROM number WHERE name='first'
>> 2023-08-21 11:51:50.656 CEST [1511] user@testdb LOG: execute S_1: SELECT dim1 FROM number WHERE name=‘first'
>
> Are these outputs from the same run?
Yes
>
> I notice that the output from the program switches after 5 queries from
> "-1" to "-1-0", but the logged query name switches after 4 queries from
> "<unnamed>" to "S_1”.
You’re right. It seem a JDBC side problem. I am doing some tests using suggestions from pgsql-jdbc list.
What sounds strange to me is that switching from “mode_X” to “mode_Y” I obtain different representation of the same value,
I know the value is semantically the same.. but… in some way I like to see.. "a perfect postgresql env” (as it absolutely is)
EdoardoI have confirmed that this behaviour is by design either by postgres or the driver. When postgres provides us the data using text mode we see -1(psql)select * from number ;name | dim1-------+------first | -1This is the way the data is presented by the text output function.In binary mode we see -1.0. This is an artifact of the binary output function.If ResultSet.getDouble is used the data is the same ... -1 for both text and binaryUsing getString we see the problem.So you have a few options to stop this: Set prepareThreshold to 0 and the driver will not switch to named statements or binary,Properties props = new Properties();props.setProperty("prepareThreshold", "0");Connection conn = DriverManager.getConnection("jdbc:postgresql://192.168.64.7:5432/testdb?user=user&password=password”, props);Obtains “-1” all the times
You do give up the advantage of named statements which is that DESCRIBE won't be necessary, but that does appear to be less of a problem than returning a different representation.
Dave
pgsql-general by date: