Euler Taveira de Oliveira wrote:
> Bruce Momjian wrote:
>
> > OK, I researched this and realized it should have been obvious to me
> > when I added this code in 2006 that making the thousands separator
> > always "," for a locale of "" was going to cause a problem.
> >
> I tested your patch and IMHO it breaks the glibc behavior. I'm providing
> a SQL script [1] and a diff [2] showing the differences between before
> and after applying it. In [2], I see a lot of common used (pt_*, es_*,
> and fr_*) locales that we'll be changed. Is it the behavior we want to
> support? I think we shouldn't try to fix glibc bug inside PostgreSQL (in
> this case, use should accept "" as a possible value for thousands_sep).

I am confused. You stated in your earlier email:

> Looking again at bug report [1], I agree that's a glibc bug. Numbers
> in pt_BR has its format 1.234.567,89; sometimes the format 1234567,89
> is acceptable too, ie, the thousand separator is optional. I guess

so I assumed that you were OK with having "." be the thousands
separator. I think we have to try to get a proper fix even if glibc is
incorrect. The problem we had with psql print.c is that when we didn't
provide a "." default we had people complaining about that. The idea I
think is that if people are asking for a thousands separator in the
to_char() format they certainly want to see a thousands separator.

The backend behavior now matches the psql numericlocale behavior which
was accepted a while back.

> > I don't think there is any change needed for the C locale. That part
> > seems fine, as Alvaro already pointed out.
> >
> I don't know about C locale, but it's broken too. In PostgreSQL, it's
> following the en_US behavior. Comments?
>
> euler@harman:/a/pgsql$ ./a.out C
> decimal_point: "."
> thousands_sep: ""
> euler@harman:/a/pgsql$ ./a.out en_US
> decimal_point: "."
> thousands_sep: ","

Yes, I think that is correct.

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

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

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Bruce Momjian wrote:

> I am confused. You stated in your earlier email:
>
>> Looking again at bug report [1], I agree that's a glibc bug. Numbers
>> in pt_BR has its format 1.234.567,89; sometimes the format 1234567,89
>> is acceptable too, ie, the thousand separator is optional. I guess
>
> so I assumed that you were OK with having "." be the thousands
> separator. I think we have to try to get a proper fix even if glibc is
> incorrect. The problem we had with psql print.c is that when we didn't
> provide a "." default we had people complaining about that. The idea I
> think is that if people are asking for a thousands separator in the
> to_char() format they certainly want to see a thousands separator.
>
Maybe I'm not so clear (too few caffeine) but what I tried to say
(suggest) is that we could accept the thousands_sep from glibc instead
of guessing it ("."). I'm fine with the current behavior (at least in
pt_BR) but I'm afraid we have broken some locales (those that a
presented in the lcnumeric.diff).


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

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Euler Taveira de Oliveira wrote:
> Bruce Momjian wrote:
>
> > I am confused. You stated in your earlier email:
> >
> >> Looking again at bug report [1], I agree that's a glibc bug. Numbers
> >> in pt_BR has its format 1.234.567,89; sometimes the format 1234567,89
> >> is acceptable too, ie, the thousand separator is optional. I guess
> >
> > so I assumed that you were OK with having "." be the thousands
> > separator. I think we have to try to get a proper fix even if glibc is
> > incorrect. The problem we had with psql print.c is that when we didn't
> > provide a "." default we had people complaining about that. The idea I
> > think is that if people are asking for a thousands separator in the
> > to_char() format they certainly want to see a thousands separator.
> >
> Maybe I'm not so clear (too few caffeine) but what I tried to say
> (suggest) is that we could accept the thousands_sep from glibc instead
> of guessing it ("."). I'm fine with the current behavior (at least in
> pt_BR) but I'm afraid we have broken some locales (those that a
> presented in the lcnumeric.diff).

Yea, I am afraid we will have to wait for feedback during 8.3 to see.
We did hammer out the psql behavior with quite a bit of discussion so I
am hopeful doing the same in the backend will help. The new code is
certainly better than what was there before because no one wants the
thousands separator to be the same as the decimal point, so at least
that is a fix, and it seems better for your language. Basically we have
never treated "" as no thousands separator and I don't remember anyone
asking for that behavior.

If we want to start honoring "" as really no thousands separator we are
going to have to have additional discussion and go back and read from
the many people who complained when we had that behavior. I know most
people didn't like the C locale having "" for thousands separator so we
had to hard-code that.

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

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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend