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 <t...@sss.pgh.pa.us>: > Ron <ronljohnso...@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 > > >