You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From #72 , @jeremyrsmith raises a question about supporting additional Charsets for Postgres. Currently we are locked in to StandardCharsets.UTF_8 throughout the code base.
Postgres gives us the current encoding of the Server through a Parameter Status update which can come at any point during the connection.
The question I have going forward - is this something we should automatically detect from Postgres and attempt to make it transparent to a user? Or should we set the encoding through Stack.Param configuration and immediately close the connection if the encoding ever changes from the Server?
The text was updated successfully, but these errors were encountered:
I think a good first step would be to proliferate a Charset everywhere that decoding needs to be done. For now we could just hard-code StandardCharsets.UTF_8 in those positions, but having them available and used inside decoders will make it possible to support dynamic Charsets either by reading it from the server or allowing the user to specify it.
From #72 , @jeremyrsmith raises a question about supporting additional Charsets for Postgres. Currently we are locked in to
StandardCharsets.UTF_8
throughout the code base.Postgres gives us the current encoding of the Server through a Parameter Status update which can come at any point during the connection.
The question I have going forward - is this something we should automatically detect from Postgres and attempt to make it transparent to a user? Or should we set the encoding through
Stack.Param
configuration and immediately close the connection if the encoding ever changes from the Server?The text was updated successfully, but these errors were encountered: