-
Notifications
You must be signed in to change notification settings - Fork 868
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't send extra_float_digits for PostgreSQL 12+ by default #3432
Comments
PgBouncer should be configured with |
I address precisely this thing in the context section. But that doesn't answer the secondary main concern: why reduce arbitrary the float precision? Why should we send 2 instructions to get the native precision when none is required at all? |
https://www.postgresql.org/docs/17/datatype-numeric.html#DATATYPE-FLOAT
|
Same link, but the information is the the same since 2019. So I was wrong assuming you needed to reset it to get full precision. Since version 12 it is not needed anymore, so the breaking of PgBouncer default conf on PostgreSQL 12+ is even more meaningless. |
Describe the issue
Connecting through PgBouncer with a default configuration fails.
Driver Version?
All supported.
Java Version?
All supported.
OS Version?
All supported.
PostgreSQL Version?
To Reproduce
Connect throught PgBouncer. Fails with unsupported extra_float_digits parameter.
Expected behaviour
Connected to the database.
Context
extra_float_digits has been introduced in PostgreSQL 8.4 to play around the apparent precision of the lossy datatype "float". At first to increase the precision sent to the client, then since version 12, to reduce it. In pgJDBC, if you want the "full" precision with a server 12+, you must override this parameter since it is forced in the driver to the value 3 if the server is 9+, that means you have to send it twice to the server. Furthermore, by default it's not authorized by default with PgBouncer: "the internet" answer is to change the server, whereas it doesn't make really sense to send it at all for PostgreSQL 12+. (And the question of forcing a default for the lossy datatype should be asked... in my view it should be an explicit choice from the application owner).
The text was updated successfully, but these errors were encountered: