[prev in list] [next in list] [prev in thread] [next in thread]
List: postgresql-general
Subject: Re: [GENERAL] Problem with pg_dump and decimal mark
From: Eric Svenson <esvenson74 () googlemail ! com>
Date: 2014-11-29 8:25:24
Message-ID: CABhsftgMx2SujccH9v2tU6x1R7vo7Bzp6ZDNib7eFTg=RvjTsw () mail ! gmail ! com
[Download RAW message or body]
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
[Attachment #3 (text/html)]
<div dir="ltr"><br><div class="gmail_extra"><br><div \
class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div \
class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> Seems you have a locale mismatch \
issue. The dump is coming from a locale<br> where a '.' is the decimal mark \
and is being restored to a locale where<br> ',' is the mark. Look at what the \
locales are the machines that work and<br> the one that does not.<br>
</blockquote>
<br></blockquote></div></div></blockquote><div><br></div><div>I have already done \
that and found something strange:<br><br></div><div>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)<br><br></div><div>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<br><br></div><div>On the second PC (Virtual Machine) I had the SAME \
settings in postgresql.conf (German_Germany)<br><br></div><div>-> no \
success<br><br></div><div>I tried to change all the settings to English/United \
States, restart postgres<br><br></div><div>-> still no \
success<br><br></div><div>Changed all Windows settings to English / United \
States<br><br></div><div>-> still no success.<br><br></div><div>So what I am \
searching for (at the moment without success) is the 'switch' which decides \
what decimal seperator to expect by psql.<br></div><div> </div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> That's what it sounds like all right, but how could that \
be? The behavior<br> of float8in/float8out is not supposed to be \
locale-dependent.<br> <br>
float8in does depend on strtod(), whose behavior is locale-dependent<br>
according to POSIX, but we keep LC_NUMERIC set to "C" to force it to<br>
only believe that "." is decimal point.<br>
</blockquote>
<br></div></div>
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.</blockquote><div><br></div><div>This \
is correct. <br><br><br></div><div>regards and thanks for your support,<br>Eric \
Svenson<br></div><div> </div></div><br></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic