Обсуждение: lc_numeric and decimal delimiter

Hi all,

I am at OpenDBCon in Germany. People are complaining about floats/numerics
not accepting German/European conventions for the delimiter point -- a
comma. This is hard coded into the the numeric input parser but,
naturally, we use strtod() in else where. I'm not sure about the locale
stuff and whether it deals with it. Are we in the wrong here?

Thanks,

Gavin

Gavin Sherry <swm@linuxworld.com.au> writes:
> I am at OpenDBCon in Germany. People are complaining about floats/numerics
> not accepting German/European conventions for the delimiter point -- a
> comma. This is hard coded into the the numeric input parser but,
> naturally, we use strtod() in else where. I'm not sure about the locale
> stuff and whether it deals with it. Are we in the wrong here?

This has been proposed and rejected in the past.  I don't think it's an
open-and-shut decision.  Given that our trend has been to tighten rather
than loosen input error checking (eg, no empty strings for int4, no
heuristic month/day choices for timestamps), I'd be inclined to vote
against it still.
        regards, tom lane

Gavin Sherry wrote:

> I am at OpenDBCon in Germany. People are complaining about floats/numerics
> not accepting German/European conventions for the delimiter point -- a
> comma. This is hard coded into the the numeric input parser but,
> naturally, we use strtod() in else where. I'm not sure about the locale
> stuff and whether it deals with it. Are we in the wrong here?

Yes.  Unless you consider it reasonable to expect applications to parse
numeric input from users to change the decimal and thousands separators.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Gavin Sherry wrote:

>Hi all,
>
>I am at OpenDBCon in Germany. People are complaining about floats/numerics
>not accepting German/European conventions for the delimiter point -- a
>comma. This is hard coded into the the numeric input parser but,
>naturally, we use strtod() in else where. I'm not sure about the locale
>stuff and whether it deals with it. Are we in the wrong here?
>  
>

If we are it is apparently by design. pg_locale.c says:
 * The other categories, LC_MONETARY, LC_NUMERIC, and LC_TIME are also* settable at run-time.  However, we don't
actuallyset those locale* categories permanently.  This would have bizarre effects like no* longer accepting standard
floating-pointliterals in some locales.* Instead, we only set the locales briefly when needed, cache the* required
informationobtained from localeconv(), and set them back.* The cached information is only used by the formatting
functions*(to_char, etc.) and the money type.
 


Personally, I am inclined to think there should at least be a setting 
that allows input according to locale settings, even if it would 
disallow "standard" floating point strings. Maybe one of the protesting 
Europeans  would like to make a proposal?

cheers

andrew

Gavin Sherry wrote:
> I am at OpenDBCon in Germany. People are complaining about
> floats/numerics not accepting German/European conventions for the
> delimiter point -- a comma.

Supporting localized input formats everywhere (numbers, geometric 
objects, date/time, arrays, etc.) will create dozens of incompatible 
PostgreSQL variants.

I think a preferrable solution would be use an updatable view that has, 
say, to_numeric tied in somewhere.

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