Re: [BUGS] wrong behavior using to_char()
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/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] wrong behavior using to_char()
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/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] wrong behavior using to_char()
Tom Lane wrote:
> "Euler Taveira de Oliveira" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [BUGS] wrong behavior using to_char()
"Euler Taveira de Oliveira" <[EMAIL PROTECTED]> 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
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
[BUGS] wrong behavior using to_char()
Hi,
I notice a strange behavior using to_char() function. I'm using locale
pt_BR but it could happen with any locale.
template1=# select to_char(12345.67, '999G999D999');
to_char
--
12,345,670
(1 registro)
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.
--
Euler Taveira de Oliveira
http://www.timbira.com/
x
Description: Binary data
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [BUGS] pgsql on Solaris 10
Based on the date of the posting, I think this will be fixed when we release 8.1.5 soon. If you want, use CVS to pull the 8_1 tag and try that. --- [EMAIL PROTECTED] wrote: > Compiling PostgreSQL 8.1.4 under Solaris 10, I ran into a problem documented > back on 2006-05-30. Apparently in order to compile successfully, one has to > remove an unreferenced function pqsignalinquire() in > src/interfaces/libpq/pqsignal.c. > > Since I stepped into this hole, is there anything I can do to help ensure > that nobody else has to get lost on Google for several hours tracking down > the same problem? I have been a Free Software user for some time but am not > familiar with ways of feeding back into the process. > > Thanks, > > Victor Odhner > > - > > Details of the problem: > > Removing the function eliminated the following error when linking "initdb": > > Undefined symbol--first referenced in file > > sigmask --../../../src/interfaces/libpq/libpq.so > > sigblock --../../../src/interfaces/libpq/libpq.so > > ld: fatal: Symbol referencing errors. No output written to initdb > > My guidance came from a posting by Tom Lane, 2006-05-30 -- >http://archive.netbsd.se/?ml=pgsql-admin&a=2006-05&t=2058700 dated > 2006-05-30 > > The rest of this message digests that posting. > > Tom Lane Quoted Bruce Momjian from another discussion: > 2004-01-08 21:02 momjian > > * doc/src/sgml/libpq.sgml, src/backend/nodes/read.c, > src/interfaces/libpq/fe-connect.c, src/interfaces/libpq/fe-print.c, > src/interfaces/libpq/fe-secure.c, src/interfaces/libpq/libpq-fe.h, > src/interfaces/libpq/libpq-int.h, src/interfaces/libpq/pqsignal.c, > src/interfaces/libpq/pqsignal.h: Allow libpq to do thread-safe > SIGPIPE handling. This allows it to ignore SIGPIPE from send() in > libpq, but terminate on any other SIGPIPE, unless the user installs > their own signal handler. > > This is a minor fix because the only time you get SIGPIPE from > libpq's send() is when the backend dies. > > The code appears to unconditionally assume that sigmask() and sigblock() > exist. > Not a good assumption. > > (End of Momjian quote; Tom Lane continued . . .) > > AFAICS pqsignalinquire() isn't even used anywhere (at least not in > HEAD), so the simplest answer may be to remove it rather than try to > fix it. It's in src/interfaces/libpq/pqsignal.c. > > (V.Odhner comment: This worked for the person who started that discussion, > and it seems to have worked for me.) > > - > > > ---(end of broadcast)--- > TIP 2: Don't 'kill -9' the postmaster -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
