Re: Problem with pg_dump and decimal mark

From: Eric Svenson <esvenson74(at)googlemail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Problem with pg_dump and decimal mark
Date: 2014-11-29 08:25:24
Message-ID: CABhsftgMx2SujccH9v2tU6x1R7vo7Bzp6ZDNib7eFTg=RvjTsw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Seems you have a locale mismatch issue. The dump is coming from a locale
>>> where a '.' is the decimal mark and is being restored to a locale where
>>> ',' is the mark. Look at what the locales are the machines that work and
>>> the one that does not.
>>>
>>
>>
I have already done that and found something strange:

On the PC where the backup was done with pg_dump, all locale settings of
Postgres were English/United States. (LC_COLLATE, LC_CTYPE, LC_MONETARY,
LC_NUMERIC in postgresql.conf)

On the first PC on which I tried to load the backup file with psql, all
locale settings if Postgres were German_Germany. Everything is ok, the SQL
file with '.' as decimal point was accepted without a problem

On the second PC (Virtual Machine) I had the SAME settings in
postgresql.conf (German_Germany)

-> no success

I tried to change all the settings to English/United States, restart
postgres

-> still no success

Changed all Windows settings to English / United States

-> still no success.

So what I am searching for (at the moment without success) is the 'switch'
which decides what decimal seperator to expect by psql.

> That's what it sounds like all right, but how could that be? The behavior
>> of float8in/float8out is not supposed to be locale-dependent.
>>
>> float8in does depend on strtod(), whose behavior is locale-dependent
>> according to POSIX, but we keep LC_NUMERIC set to "C" to force it to
>> only believe that "." is decimal point.
>>
>
> Not sure if this makes a difference but if I am reading the original post
> correctly the OP was trying a plain text restore via psql.

This is correct.

regards and thanks for your support,
Eric Svenson

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Benjamin Rutt 2014-11-29 20:27:07 When was ANALYZE run in the past?
Previous Message Joshua Boyd 2014-11-28 22:29:40 Postgres 9.2 PITR testing to before DROP DATABASE ends up removing file system files