Thank you, Tom.
I tried patched file and it works fine now (with Russian locale both in
Linux and Windows).
I've noticed that you strict mon_decimal_point to one char, but at least
two locales (fa_IR and ps_AF) (I looked at glibc-2.14) define
mon_decimal_point as "<U066B>" so it takes two bytes.
And IMHO the locale sanity check better move to PGLC_localeconv and
don't perform these checks with each number conversion.
Best regards,
Alexander.
30.10.2011 23:09, Tom Lane пишет:
Alexander Lakhin<exclus...@gmail.com> writes:
I think there is no need to leave such assumptions. I would propose the
following fix:http://pastebin.com/EBw5YB65 (it corrects a BUG #6144 too)
I can send it as a patch if you wish. Please notice a comments regarding
regression tests. IMHO at least currency symbol separator should be
processed as specified in lconv. And maybe mon_decimal_point,
currency_symbol and negative_sign should be allowed to be empty too if
it's defined by a locale.
I've committed a patch that improves the handling of cs_precedes,
sign_posn et al. I don't agree with your proposal to slavishly follow
the locale definition no matter how brain-dead it is, because that would
destroy the ability to dump and reload data without data loss --- for
example, if we obeyed an empty negative_sign setting, we'd lose the
information that a value had been negative. AFAICT there are no such
locales anyway, other than POSIX for which we definitely don't want to
believe the empty-string setting.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
