Is it the Netherlands where the convention is to use "," for a decimal
point as in "1.000.000,00"?
I don't think this is a battle we can win, and I'm a little surprised we
try. We'd almost have a fighting chance on the client if the user could
tweak locale settiings for the CSV loader -- but it seems like we're
handling this at a point too deeply embedded in the server to be that
flexible, so I guess we lose the Netherlands.

I think I just "got" the backslashes -- they are probably there in the CSV
file to prevent the commas from doing their CSV thing but nothing bothers
to unescape them after the CSV field parsing.


On Tue, Jun 25, 2013 at 9:41 PM, John Hugg <notifications@github.com> wrote:

> In src/frontend/org/voltdb/ParameterConverter.java:
>
> >
> > -        if (param instanceof SystemProcedureExecutionContext) {
> > -            return param;
> > +    /**
> > +     * Given a string, covert it to a primitive type or return null.
> > +     */
> > +    private static Object convertStringToPrimitive(String value, final Class<?> expectedClz)
> > +    throws Exception
> > +    {
> > +        value = value.trim();
> > +        // detect CSV null
> > +        if (value.equals(VoltTable.CSV_NULL)) return nullValueForType(expectedClz);
> > +        // remove commas and escape chars
> > +        value = value.replaceAll("\\,","");
>
> Well the commas make sense to me – they allow us to parse "1,000.00" from
> a CSV file, which the built-in parsers seem to choke on. I'm not sure if
> that will cause issues in the Netherlands, which has given us trouble in
> the past.
> I must admit I forget why the slashes are there and that was puzzling me
> too. I don't plan to remove it unless I can explain why that's safe.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/VoltDB/voltdb/pull/580/files#r4882589>
> .
>