lc_numeric and decimal delimiter

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 <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:

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 actually set those locale
* categories permanently. This would have bizarre effects like no
* longer accepting standard floating-point literals in some locales.
* Instead, we only set the locales briefly when needed, cache the
* required information obtained 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/