Кстати, про кодировки - база 1251, клиент 1251, но при

использовании to_char для числа c символом формата "D" пытается сунуть юникод и все ломается. Никто не сталкивался?

все точно в 1251, так то, все работает нормально

А, ну раз нормально — тогда не о чем беспокоиться.

я имею ввиду, что только вот в этом месте вылезает странность. а не рекомендуется делать 1251?

Да как сказать... В общем, если надо — то почему бы и не сделать. Но как-то время такое, что это довольно странно.

Ну, покажыте что ли запрос и какую ошыбку выдаёт. Заодно — \l на этом сервере. (На всякий случай говорю заранее: текстом покажыте).

SELECT to_char(122.22,'999990D00'); SQL Error [22P05]: ERROR: character with byte sequence 0xe2 0x82 0xbd in encoding "UTF8" has no equivalent in encoding "WIN1251" vvv | postgres | WIN1251 | ru_RU.cp1251 | ru_RU.cp1251 | postgres | postgres | UTF8 | ru_RU.utf8 | ru_RU.utf8 | template0 | postgres | UTF8 | ru_RU.utf8 | ru_RU.utf8 | =c/postgres + | | | | | postgres=CTc/postgres template1 | postgres | UTF8 | ru_RU.utf8 | ru_RU.utf8 | =c/postgres + | | | | | postgres=CTc/postgres

А, это не timestamp ещё. Смешно. В первом приближэнии похожэ не баг.

Так. Нет. Стоп. ru_RU.cp1251 ? То есть это сервер на юниксе? Каком юниксе? И да, SELECT version() ещё покажыте.

linux, какой не знаю. PostgreSQL 15.3 (IvorySQL 2.3) on x86_64-pc-linux-gnu, compiled by gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516, 64-bit|

Похожэ, баг в 15 постгресе.

значит будем все D менять на точку)

Можно ещё сказать ALTER DATABASE vvv SET lc_monetary='en_US.utf8' Ну, или C. Но ваш вариант мне нравится большэ! (Никогда не видел никакой пользы от запятой в качестве отделителя дробной части — а вреда видел много).

да это код из Oracle, там все было с "D", по мне так правильнее, хотя и понятно, что запятой там никогда не будет

Ну... Кагбы при правильной работе оно бы выдало запятую. Так что "никогда не будет" запятой там — только если выкинете это D.

OMG - U+20BD ₽ 0xe2 0x82 0xbd

Да, видимо компилирует при первом обращении всю потребную часть локали — и падает на рубле этом. Жэлающие ещё могут поправить /usr/share/i18n/locales/ru_RU и перезапустить locale-gen. Но это как-то выглядит ещё геморройнее, чем поставить базе lc_monetary=C (или удалить эти все D).

спасибо, навели меня на мысль, вот это помогло - set lc_monetary to 'C'; set lc_numeric to 'POSIX';

0xE2 0x82 0xBD — это знак рубля

Я тут почесал немного всякие варианты — и выяснил, что баг связан не с 16 версией постгреса. А с тем, с какой локалью кластер создан изначально! То есть создаёшь с ru_RU.utf8 — и в базе, сделанной через create database ilank template='template0' encoding='koi8-r' owner='ilan' locale='ru_RU.KOI8-R'; форматирование падает из-за символа рубля. Создаёшь типа LANG=ru_RU.koi8-r pg_createcluster 15 testlocale — и такжэ созданные базы нифига не падают, а символ рубля ВНЕЗАПНО становится 'руб' (три буквы, да).

Ну глюк есть глюк) вроде обошел его, но неприятно, конечно

Ща пачку форвардов пришлю: с телефона переписывать лент.