Re: PostgresSQL 10 | Driver 42.2.5 | Float Conversion Issue
От | Tom Lane |
---|---|
Тема | Re: PostgresSQL 10 | Driver 42.2.5 | Float Conversion Issue |
Дата | |
Msg-id | 675895.1603225986@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: PostgresSQL 10 | Driver 42.2.5 | Float Conversion Issue (Vladimir Sitnikov <sitnikov.vladimir@gmail.com>) |
Ответы |
Re: PostgresSQL 10 | Driver 42.2.5 | Float Conversion Issue
Re: PostgresSQL 10 | Driver 42.2.5 | Float Conversion Issue |
Список | pgsql-jdbc |
Vladimir Sitnikov <sitnikov.vladimir@gmail.com> writes: > https://www.postgresql.org/docs/13/datatype-numeric.html#DATATYPE-FLOAT > The documentation says that PostgreSQL implements IEEE Standard 754. Note the waffling immediately after that, though. > 1234567 is exactly representable in IEEE (e.g. see > https://www.exploringbinary.com/floating-point-converter/ ), > so I would expect the database should keep the value intact. You don't really get to have your cake and eat it too. Yeah, we could allow more than six digits to propagate through float4_numeric, but then some cases would result in surprising garbage digits showing up in the result. That would annoy at least as many people as the current behavior. > In case that matters, pgjdbc does send pass extra_float_digits=2 in the > initial packet, then it upgrades to extra_float_digist=3 in case server > version is 9.0+ Hmm, but it's done that for a long while, no? Doesn't seem to explain the behavior change the OP is complaining of. > I did try removing that parameter, and it does not resolve > 1234567::float4::numeric::text issue Of course not, that conversion is happening entirely inside the backend; extra_float_digits isn't involved. (Although it would get involved with 1234567::float4::text::numeric, I bet, since the float4 -> text step would pay attention to it.) regards, tom lane
В списке pgsql-jdbc по дате отправления: