Re: insert column monetary type ver 2
Дмитрий Иванов <firstdismay@gmail.com>
From: Дмитрий Иванов <firstdismay@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Ron <ronljohnsonjr@gmail.com>, "pgsql-general@lists.postgresql.org" <pgsql-general@lists.postgresql.org>
Date: 2021-11-22T15:57:20Z
Lists: pgsql-general
About the locale, I wanted to add a couple of lines. I noticed a strange behavior of the currency symbol. The EDB installer, when specifying the Russian locale, sets the following locale parameters: (PostgreSQL 12.9, compiled by Visual C++ build 1914, 64-bit) (Encoding UTF8) lc_messages = 'Russian_Russia.1251' # locale for system error message # strings lc_monetary = 'Russian_Russia.1251' # locale for monetary formatting lc_numeric = 'Russian_Russia.1251' # locale for number formatting lc_time = 'Russian_Russia.1251' # locale for time formatting In this case, the data of the financial type is not correctly displayed: 1 238,23 ? If you set the locale: lc_messages = 'ru_RU.UTF-8' # locale for system error message # strings lc_monetary = 'ru_RU.UTF-8' # locale for monetary formatting lc_numeric = 'ru_RU.UTF-8' # locale for number formatting lc_time = 'ru_RU.UTF-8' # locale for time formatting The data of the financial type is displayed correctly: 1 238,23 ₽ -- Regards, Dmitry! пн, 22 нояб. 2021 г. в 20:17, Tom Lane <tgl@sss.pgh.pa.us>: > Ron <ronljohnsonjr@gmail.com> writes: > > On 11/21/21 9:35 PM, Rob Sargent wrote: > >> Some of us like it as an easy formatter trick for reports > > > to_char() can do the same, no? > > to_char doesn't have adequate logic for locale-specific monetary > formatting. > You can get it to emit a locale-specific currency symbol, but it has no > clue whether that should go before or after the value. It knows nothing > of other locale-specific details, such as possibly using parens in place > of a minus sign. Also, the POSIX API allows monetary decimal point and > thousands separators to be different from the numeric ones that to_char > knows about. (I have no idea which locales use that, but I doubt they'd > have put in that complication without need.) > > regards, tom lane > > >