Locale number format confusion - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Locale number format confusion
Date
Msg-id Pine.LNX.4.44.0208082254190.927-100000@localhost.localdomain
Whole thread Raw
Responses Re: Locale number format confusion
Re: Locale number format confusion
List pgsql-hackers
It seems we need a smart plan for handling the decimal point vs. comma
issue.  Observe:  (lc_numeric = de_DE)

create table test_f (x double precision);
CREATE TABLE
insert into test_f values ('1.5');
ERROR:  Bad float8 input format '1.5'
insert into test_f values ('1,5');
INSERT 16909 1

create table test_n (x numeric);
CREATE TABLE
insert into test_n values ('1.5');
INSERT 16915 1
insert into test_n values ('1,5');
ERROR:  Bad numeric input format '1,5'

create table test_p (x point);
CREATE TABLE
insert into test_p values ('(1.5, 2.4)');
ERROR:  Bad point external representation '(1.5, 2.4)'
insert into test_p values ('(1,5, 2,4)');
INSERT 16918 1
insert into test_p values ('(9,5)');
ERROR:  Bad point external representation '(9,5)'
peter=# insert into test_p values ('(9,5,1)');
INSERT 16919 1

select * from test_p;    x
-----------(1,5,2,4)(9,5,1)    -- (What point is that?)

(Yes, we really need structured types, not the parse-your-own-string
extension interface.)

SQL99 effectively says that a decimal *point* should be used for casts
from numerical to character types and vice versa.  (You can read about
this in 6.22 GR 6b, 7b, 8a, 8b -- there are pretty specific rules for
converting numbers to strings which we probably don't follow very
strictly.)

I propose that we do this (probably by writing our own strtod and
friends).  If you want to format your numbers to local convention,
to_char() can be used.

Comments?

-- 
Peter Eisentraut   peter_e@gmx.net



pgsql-hackers by date:

Previous
From: Oleg Bartunov
Date:
Subject: postgresql performance tuning document ?
Next
From: "Nigel J. Andrews"
Date:
Subject: Re: Linux Largefile Support In Postgresql RPMS