|
Notes |
|
|
|
Attached for your reference the Format.xml and postgresql.conf. Note that the same configuration works fine in PG 9.1.
Assigned initial to platform, but feel free to forward to Finance team if necessary |
|
|
|
|
Hi,
i just tested it cannot reproduce that. I get the expected 1.53 in both 9.1 & 9.3
But that sounds very similar to another config problem Eduardo reported just a few days ago.
Please compare all 'lc_*' lines in postgresql.conf in the bost systems where you see the difference. |
|
|
|
|
@shuehner: lc_* are exactly the same in both 9.1 and 9.3.
I have attached the diff of postgresql.conf file between the 2 versions.
In general they are quite similar.
The problem might be here:
< #timezone = '(defaults to server environment setting)'
---
> #timezone = 'localtime'
As you can see timezone is commented in both files, but maybe the way PG gets the default value might be different creating the problem |
|
|
|
|
timezone has nothing to do with number formatting at all so highly unlikely.
But as said alo has a idea already and is looking into it.
If you want to test his idea, change lc_monetary to en_US.UTF-8
and maybe your issue will go away. |
|
|
|
|
This is caused by lc_numeric setting together with a behavior change introduced in PostgreSQL 9.3:
[1] Fix to_number() to properly handle a period used as a thousands separator (Tom Lane)
Previously, a period was considered to be a decimal point even when the locale says it isn't and the D format code is used to specify use of the locale-specific decimal point. This resulted in wrong answers if FM format was also used.
This causes:
======
PG 9.1
======
to_number result is independent from locale
pi91=# set lc_numeric='es_ES.UTF-8';
SET
pi91=# show lc_numeric;
lc_numeric
-------------
es_ES.UTF-8
(1 row)
pi91=# select to_number('1.2');
to_number
-----------
1.2
(1 row)
pi91=# set lc_numeric='en_US.UTF-8';
SET
pi=# select to_number('1.2');
to_number
-----------
1.2
(1 row)
======
PG 9.3
======
to_number result DEPENDS on locale
pi=# set lc_numeric='es_ES.UTF-8';
SET
pi=# show lc_numeric;
lc_numeric
-------------
es_ES.UTF-8
(1 row)
pi=# select to_number('1.2');
to_number
-----------
12
(1 row)
pi=# select to_number('1,2');
to_number
-----------
1.2
(1 row)
pi=# set lc_numeric='en_US.UTF-8';
SET
pi=# select to_number('1.2');
to_number
-----------
1.2
(1 row)
==========
Workaround
==========
Set lc_numeric = 'en_US.UTF-8' in postgreqsl.conf and reload server.
---
[1] http://www.postgresql.org/docs/9.3/static/release-9-3.html [^] |
|
|
|
|
More info:
1. Tried changing lc_monetary = en_US.UTF-8 (or en_US) gave the following error when restarting database:
[....] Restarting PostgreSQL 9.3 database server: main[....] The PostgreSQL server failed to start. Please check the log output: 2015-06-04 17:51:00 CEST [27343-1] LOG: 22023: valor no válido para el parámetro «lc_monetary»: «en_US.UTF-8» 2015-06-04 17:51:00 CEST [27343-2] UBICACIÓN: call_string_check_hook, guc.c:8332 2015-06-04 17:51:01 CEST [27343-3] FATAL: F0000: el archivo de configuración «/etc/postgresql/9.3/main/postgresql.conf» contiene errores 2015-06-04 17:51:[FAILST [27343-4] UBICACIÓN: ProcessConfigFile, guc-file.l:352 ... failed!
failed!
2. If I delete the following lines in the postgresql.conf, the issue is not reproducible:
lc_messages = 'es_ES.UTF-8' # locale for system error message
# strings
lc_monetary = 'es_ES.UTF-8' # locale for monetary formatting
lc_numeric = 'es_ES.UTF-8' # locale for number formatting
lc_time = 'es_ES.UTF-8' # locale for time formatting |
|
|
|
|
|
|
|
(0078163)
|
|
hgbot
|
|
2015-06-09 18:03
|
|
Repository: erp/devel/pi
Changeset: 780731085f0c277f8c3f6778a328c38fc5dca667
Author: Carlos Aristu <carlos.aristu <at> openbravo.com>
Date: Tue Jun 09 18:01:36 2015 +0200
URL: http://code.openbravo.com/erp/devel/pi/rev/780731085f0c277f8c3f6778a328c38fc5dca667 [^]
Fixes issue 30069: Critical bug with decimals only in PostgreSQL 9.3
A new build validation has been added. This way, when executing update.database the result returned by the to_number() procedure is evaluated.
In case it does not return the expected result, the task will fail, showing a message with the link to the documentation
---
A src-util/buildvalidation/build/classes/org/openbravo/buildvalidation/DatabaseDecimalNumberCheck.class
A src-util/buildvalidation/build/classes/org/openbravo/buildvalidation/DatabaseDecimalNumberCheckData.class
A src-util/buildvalidation/src/org/openbravo/buildvalidation/DatabaseDecimalNumberCheck.java
A src-util/buildvalidation/src/org/openbravo/buildvalidation/DatabaseDecimalNumberCheck_data.xsql
---
|
|
|
|
|
|
|
|
|
|
|
|
|
code reviewed
tested in pg9.3 having es_ES as lc_numeric build validation fails not allowing to continue |
|
Format.xml (3,243) 2015-06-02 09:30
postgresql.conf (20,710) 2015-06-02 09:30
postgresql_91vs93_conf.diff (5,986) 2015-06-02 11:38