Re: BUG #6277: Money datatype conversion wrong with Russian locale

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<exclusion@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