From: | Dave Cramer <davecramer(at)postgres(dot)rocks> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | 姜梦洋 <minesunny(at)icloud(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: the same time value return different values,is it a problem |
Date: | 2023-09-17 11:33:06 |
Message-ID: | CADK3HH+SkUH=TjJkbh=Lo=tQk-mNAG5v0wZ6xqwqjcpzxLxc_w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Fri, 15 Sept 2023 at 12:58, Dave Cramer <davecramer(at)postgres(dot)rocks>
wrote:
>
>
> On Wed, 13 Sept 2023 at 10:17, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> =?utf-8?B?5aec5qKm5rSL?= <minesunny(at)icloud(dot)com> writes:
>> > I find the time type accuracy of the database. Using
>> PreparedStatement, the accuracy found out for the sixth time is different
>> from the first five times. This number is exactly the same as the threshold
>> of the PreparedStatement. I can understand that the database can optimize
>> PreparedStatements and reduce repeated parsing and other unnecessary
>> operations. but I don’t quite understand how such processing will affect
>> the execution results(Or maybe I don’t have a deep understanding of
>> PreparedStatement.).
>>
>
> What is the difference and the type of the column? I'm not about to open a
> zip file.
>
>
>
>>
>> If you're using JDBC, this is probably the same effect discussed at
>>
>>
>> https://www.postgresql.org/message-id/flat/CAKyg5Sj%3D85niw8%3DZhX-quHaCQTPhG40REi1s%2BHYF6Snz4Dfi7Q%40mail.gmail.com
>>
>> It's got something to do with retrieving the query results in binary
>> mode instead of text. The query result at the server is the same,
>> but the JDBC driver is rendering it differently.
>>
>>
> rendering is not quite right. The parsing tends to be slightly different
> in text vs binary.
>
So it is interesting that we drop the precision of time when we receive the
data in binary. I'll have a look when I have time.
Dave
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2023-09-17 20:46:17 | Re: BUG #17928: Standby fails to decode WAL on termination of primary |
Previous Message | Michael Paquier | 2023-09-17 04:25:00 | Re: BUG #18070: Assertion failed when processing error from plpy's iterator |