-----Original Message----- From: Tom Lane [mailto:tgl@xxxxxxxxxxxxx] Sent: 06 September 2017 13:36 To: Rob Northcott <Rob.Northcott@xxxxxxxxxxxxxx> Cc: pgsql-general@xxxxxxxxxxxxxx Subject: Re: Dealing with number formats when server and client are different locales Rob Northcott <Rob.Northcott@xxxxxxxxxxxxxx> writes: > Our application was written assuming that the SQL server local settings for number formats would be the same as the client machine running the application. > Now there is a need for some clients to run using UK format (full stop for decimal separator) and some to be European format (comma for decimal separator). > This is causing problems with queries sent to the server because each client app is sending query strings in its own local format and the server throws an error if it doesn't match the server settings. Hm, Postgres doesn't support comma-for-decimal-point in very many contexts, so I'm wondering exactly what your queries are like. If that usage only appears in strings that are processed with to_number() and a D format character, then maybe you can make this work, but that seems pretty restrictive. > Possible solutions I can think of are: > 1. Change the client application so it checks and server locale settings and formats numbers appropriately. > 2. Change the server settings to match the client (if this can be > set PER SESSION?) Sure. See lc_numeric. https://www.postgresql.org/docs/current/static/config-setting.html#CONFIG-SETTING-SQL-COMMAND-INTERACTION https://www.postgresql.org/docs/current/static/runtime-config-client.html#RUNTIME-CONFIG-CLIENT-FORMAT regards, tom lane ---------------------- Thanks for the reply Tom. The problem we've got is that our app (running on PCs) generates commands to send to the SQL server, such as UPDATE customers SET cus_balance = 10.4 WHERE cus_key = 'A001' This has been working historically because the clients were always UK-based. Now some users are wanting to use European setups with commas as decimals. This is fine inside the application itself but any SQL command strings generated come out in the client PC's local format settings (SET cus_balance = 10,4) and the server doesn't like that. Changing all the code to force formatting to suit the server rather than using local settings would be pretty time-consuming hence the hope that there was another way. I'll have a look at your links though - looks like it may be possible to find a workaround. Rob -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general