wrong behavior using to_char()

"Euler Taveira de Oliveira" <euler@timbira.com> writes:

In the pt_BR locale, the thousand separator is "". So it should return
12345,670. Looking at the source, I saw that the test cases for locale
properties are independent among them. I think that the correct form is to
have all-or-nothing test case or didn't test *lconv->property ("" is
evaluated to false). Attached is a patch that fixes it using the second
option.

Not unless you have a solution to the problem seen in this thread:
http://archives.postgresql.org/pgsql-patches/2006-02/msg00172.php

regards, tom lane

Tom Lane wrote:

"Euler Taveira de Oliveira" <euler@timbira.com> writes:

In the pt_BR locale, the thousand separator is "". So it should return
12345,670. Looking at the source, I saw that the test cases for locale
properties are independent among them. I think that the correct form is to
have all-or-nothing test case or didn't test *lconv->property ("" is
evaluated to false). Attached is a patch that fixes it using the second
option.

Not unless you have a solution to the problem seen in this thread:
http://archives.postgresql.org/pgsql-patches/2006-02/msg00172.php

I was going to point him to these commits to formatting.c:

date: 2006/02/12 23:48:23; author: momjian; state: Exp; lines: +3 -4
Revert because C locale uses "" for thousands_sep, meaning "n/a", while
French uses "" for "don't want". Seems we have to keep the existing
behavior.
----------------------------
revision 1.105
date: 2006/02/12 19:52:06; author: momjian; state: Exp; lines: +5 -4
Support "" for thousands separator and plus sign in to_char(), per
report from French Debian user. psql already handles "" fine.

One idea would be to handle C locale behavior differently from non-C
locale.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

"Euler Taveira de Oliveira" <euler@timbira.com> writes:

In the pt_BR locale, the thousand separator is "". So it should return

The thousands separator in pt_BR is ".".

12345,670. Looking at the source, I saw that the test cases for locale

This should be "12.345,670".

--
Jorge Godoy <jgodoy@gmail.com>

Bruce Momjian wrote:

One idea would be to handle C locale behavior differently from non-C
locale.

Right.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Jorge Godoy wrote:

In the pt_BR locale, the thousand separator is "". So it should return

The thousands separator in pt_BR is ".".

Oh, good catch. There is so much hack in my glibc. :-)

--
Euler Taveira de Oliveira
http://www.timbira.com/

Peter Eisentraut wrote:

Bruce Momjian wrote:

One idea would be to handle C locale behavior differently from non-C
locale.

Right.

I am thinking this is eomthing for 8.3.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Euler Taveira de Oliveira wrote:

Jorge Godoy wrote:

In the pt_BR locale, the thousand separator is "". So it should return

The thousands separator in pt_BR is ".".

Oh, good catch. There is so much hack in my glibc. :-)

I researched this thread:

http://archives.postgresql.org/pgsql-bugs/2006-09/msg00074.php

Ultimately, the result was that glibc was wrong in its locale settings,
and there was a suggestion to use defaults only when using the C locale.
However, I am worried there are too many locales in the field that only
define some of the locale setting, so doing defaults only for the C
locale might not work.

The minimal patch I wrote (attached), suppresses the default for the
thousands separator only if is is the same as the decimal separator. I
think this is the only area where the default could potentially match
the locale setting for another field.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce@momjian.us> writes:

Ultimately, the result was that glibc was wrong in its locale settings,
and there was a suggestion to use defaults only when using the C locale.
However, I am worried there are too many locales in the field that only
define some of the locale setting, so doing defaults only for the C
locale might not work.

The minimal patch I wrote (attached), suppresses the default for the
thousands separator only if is is the same as the decimal separator. I
think this is the only area where the default could potentially match
the locale setting for another field.

Should we really go introducing strange misbehaviors into our code to
work around an admitted glibc bug?

regards, tom lane

Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

Ultimately, the result was that glibc was wrong in its locale settings,
and there was a suggestion to use defaults only when using the C locale.
However, I am worried there are too many locales in the field that only
define some of the locale setting, so doing defaults only for the C
locale might not work.

The minimal patch I wrote (attached), suppresses the default for the
thousands separator only if is is the same as the decimal separator. I
think this is the only area where the default could potentially match
the locale setting for another field.

Should we really go introducing strange misbehaviors into our code to
work around an admitted glibc bug?

Seems there is no interest in handling this specific case, so I withdraw
the patch, but I have added a comment with a date in case we need to
revisit it.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +