Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Since the money type has a locale dependent input and output format, there 
> has 
> to be some context saved when a database dump is created.  For example, if 
> your environment uses a locale that uses the opposite point-vs-comma 
> conventions from English (e.g., de_DE), then the following will fail to 
> replicate the regression test database:

> pg_dump regression | psql foo

> The database regression has lc_monetary = C set, so this will produce C 
> output 
> piped into, say, de_DE input.

> The first problem appears to be that pg_dump --create ought to save the 
> database-specific configuration settings.  pg_dumpall gets this right.  But 
> secondly, lc_monetary ought to be saved at the top of the dump file, much 
> like client_encoding.  Unfortunately, that would probably break portability 
> of dump files between different operating systems.  Perhaps we can get away 
> with fixing --create and documenting this.  But something ought to be done 
> about this; otherwise using the money type introduces a risk of breaking 
> backup or upgrade procedures.

This risk seems rather overstated, as it's unlikely that someone using
money would choose to reload their data into a DB with a fundamentally
incompatible locale setting.  They might, however, move to a different
platform that spells the name of that locale differently --- so I concur
that adding an lc_monetary setting to pg_dump output is likely to be
a cure worse than the disease.

My inclination is to do nothing except perhaps document the issue
someplace.  But since we've never heard any actual user complaints
about it, how real is the issue?

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to