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