From: | Vincent Veyron <vv(dot)lists(at)wanadoo(dot)fr> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: unexpected character used as group separator by to_char |
Date: | 2021-03-09 21:15:04 |
Message-ID: | 20210309221504.309aba890549a6d4e3d16fda@wanadoo.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, 9 Mar 2021 13:33:19 -0700
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>
> By using "G" you are giving up control and letting your locale settings
> decide what gets output. You can continue to use to_char but take control
> back by being explicit, or pass actual numbers into and out of the database
> and let your front-end deal with presentation concerns. I suggest the
> latter.
Well, that was a fast answer :-)
Indeed, replacing "G" with \s works. However, the application is destined to be multi-lingual, and number formats vary widely between countries :
1,000.25 (US)
1'000,25 (CH)
1 000,25 (FR)
1.000,25 (GER)
etc...
So, I intended to follow this advice by Tom Lane :
https://www.postgresql-archive.org/GENERAL-setting-LC-NUMERIC-td1857521.html
Having a database with the proper lc_numeric setting for each country, and using to_char/to_number to manipulate numbers is much more appealing than writing my own parser in my front end. But this weird space is getting in my way.
--
Bien à vous, Vincent Veyron
https://marica.fr/
Logiciel de gestion des sinistres assurances, des dossiers contentieux et des contrats pour le service juridique
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-03-09 21:22:07 | Re: unexpected character used as group separator by to_char |
Previous Message | Tom Lane | 2021-03-09 20:57:28 | Re: Need help with clarification on stored procedure support in PostGreSQL database |