Обсуждение: type money causes unrestorable dump
I noticed that if you create a dump on a database containing a money
column and a certain locale, this dump is not restorable on a database
with a different locale.
Most notably, I tried dumping the regression database (which is created
with --locale=C), and then importing it into a database of my own
creation, which uses --locale=fr_CA.UTF-8.
Due to the thousands separator being different, the regression database
is not restorable on the french database.
The regression test uses for input the unadorned form:
insert into rtest_emp values ('wiech', '5000.00');
But on output, pg_dump uses the localized form:
COPY money (a) FROM stdin;
$7 000,00
\.
Surely pg_dump should be using the unadorned form as well?
--
Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J
"No hay ausente sin culpa ni presente sin disculpa" (Prov. francés)
Alvaro Herrera <alvherre@commandprompt.com> writes:
> I noticed that if you create a dump on a database containing a money
> column and a certain locale, this dump is not restorable on a database
> with a different locale.
We've been through this, no? If money doesn't print that way, there's
no obvious reason to have the type at all. Use numeric if you don't
want something with locale-specific behavior.
regards, tom lane
Tom Lane wrote: > Alvaro Herrera <alvherre@commandprompt.com> writes: > > I noticed that if you create a dump on a database containing a money > > column and a certain locale, this dump is not restorable on a database > > with a different locale. > > We've been through this, no? Hmm, true. I even replied to the thread. I forgot. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Tom Lane wrote: > Alvaro Herrera <alvherre@commandprompt.com> writes: > > I noticed that if you create a dump on a database containing a money > > column and a certain locale, this dump is not restorable on a database > > with a different locale. > > We've been through this, no? If money doesn't print that way, there's > no obvious reason to have the type at all. Use numeric if you don't > want something with locale-specific behavior. Added to TODO: * MONEY dumps in a locale-specific format making it difficult to restore to a system with a different locale -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Mon, 8 Oct 2007 22:31:31 -0400 (EDT)
Bruce Momjian <bruce@momjian.us> wrote:
> Tom Lane wrote:
> > Alvaro Herrera <alvherre@commandprompt.com> writes:
> > > I noticed that if you create a dump on a database containing a
> > > money column and a certain locale, this dump is not restorable on
> > > a database with a different locale.
> >
> > We've been through this, no? If money doesn't print that way,
> > there's no obvious reason to have the type at all. Use numeric if
> > you don't want something with locale-specific behavior.
>
> Added to TODO:
>
> * MONEY dumps in a locale-specific format making it difficult to
> restore to a system with a different locale
Considering money is deprecated, is this really needed?
Joshua D. Drake
>
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
Joshua D. Drake wrote: -- Start of PGP signed section. > On Mon, 8 Oct 2007 22:31:31 -0400 (EDT) > Bruce Momjian <bruce@momjian.us> wrote: > > > Tom Lane wrote: > > > Alvaro Herrera <alvherre@commandprompt.com> writes: > > > > I noticed that if you create a dump on a database containing a > > > > money column and a certain locale, this dump is not restorable on > > > > a database with a different locale. > > > > > > We've been through this, no? If money doesn't print that way, > > > there's no obvious reason to have the type at all. Use numeric if > > > you don't want something with locale-specific behavior. > > > > Added to TODO: > > > > * MONEY dumps in a locale-specific format making it difficult to > > restore to a system with a different locale > > Considering money is deprecated, is this really needed? We have other MONEY TODO items too. I am not sure if it is depricated or in need of major work. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Mon, 8 Oct 2007 22:42:57 -0400 (EDT)
Bruce Momjian <bruce@momjian.us> wrote:
> Joshua D. Drake wrote:
> -- Start of PGP signed section.
> > On Mon, 8 Oct 2007 22:31:31 -0400 (EDT)
> > Bruce Momjian <bruce@momjian.us> wrote:
> >
>dering money is deprecated, is this really needed?
>
> We have other MONEY TODO items too. I am not sure if it is depricated
> or in need of major work.
Right from the docs :)
Note: The money type is deprecated. Use numeric or decimal instead, in
combination with the to_char function.
Sincerely,
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
Joshua D. Drake wrote: -- Start of PGP signed section. > On Mon, 8 Oct 2007 22:42:57 -0400 (EDT) > Bruce Momjian <bruce@momjian.us> wrote: > > > Joshua D. Drake wrote: > > -- Start of PGP signed section. > > > On Mon, 8 Oct 2007 22:31:31 -0400 (EDT) > > > Bruce Momjian <bruce@momjian.us> wrote: > > > > >dering money is deprecated, is this really needed? > > > > We have other MONEY TODO items too. I am not sure if it is depricated > > or in need of major work. > > Right from the docs :) > > Note: The money type is deprecated. Use numeric or decimal instead, in > combination with the to_char function. It will be un-depricated if it is improved. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Mon, 8 Oct 2007 22:52:23 -0400 (EDT)
Bruce Momjian <bruce@momjian.us> wrote:
> Joshua D. Drake wrote:
> -- Start of PGP signed section.
> > On Mon, 8 Oct 2007 22:42:57 -0400 (EDT)
> > Bruce Momjian <bruce@momjian.us> wrote:
> >
> > > Joshua D. Drake wrote:
> > > -- Start of PGP signed section.
> > > > On Mon, 8 Oct 2007 22:31:31 -0400 (EDT)
> > > > Bruce Momjian <bruce@momjian.us> wrote:
> > > >
> > >dering money is deprecated, is this really needed?
> > >
> > > We have other MONEY TODO items too. I am not sure if it is
> > > depricated or in need of major work.
> >
> > Right from the docs :)
> >
> > Note: The money type is deprecated. Use numeric or decimal
> > instead, in combination with the to_char function.
>
> It will be un-depricated if it is improved.
The money data type has been deprecated for years. It is completely non
standard and essentially duplicative of numeric/decimal. What is the
point?
Joshua D. Drake
>
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
On Mon, 8 Oct 2007 20:02:56 -0700
"Joshua D. Drake" <jd@commandprompt.com> wrote:
> On Mon, 8 Oct 2007 22:52:23 -0400 (EDT)
> Bruce Momjian <bruce@momjian.us> wrote:
>
> > Joshua D. Drake wrote:
> > -- Start of PGP signed section.
> > > On Mon, 8 Oct 2007 22:42:57 -0400 (EDT)
> > > Bruce Momjian <bruce@momjian.us> wrote:
> > >
> > > > Joshua D. Drake wrote:
> > > > -- Start of PGP signed section.
> > > > > On Mon, 8 Oct 2007 22:31:31 -0400 (EDT)
> > > > > Bruce Momjian <bruce@momjian.us> wrote:
> > > > >
> > > >dering money is deprecated, is this really needed?
> > > >
> > > > We have other MONEY TODO items too. I am not sure if it is
> > > > depricated or in need of major work.
> > >
> > > Right from the docs :)
> > >
> > > Note: The money type is deprecated. Use numeric or decimal
> > > instead, in combination with the to_char function.
> >
> > It will be un-depricated if it is improved.
>
> The money data type has been deprecated for years. It is completely
> non standard and essentially duplicative of numeric/decimal. What is
> the point?
Please ignore this. I have asked on -hackers for clarity on the issue.
If it is not deprecated I will submit a patch to -docs.
Joshua D. Drake
>
> Joshua D. Drake
>
>
>
>
> >
>
>
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
On Mon, 8 Oct 2007 20:02:56 -0700 "Joshua D. Drake" <jd@commandprompt.com> wrote: > The money data type has been deprecated for years. It is completely non > standard and essentially duplicative of numeric/decimal. What is the > point? It may be deprecated (maybe not) and it may have drawbacks but it is not a duplication of numeric or decimal. While numeric/decimal may be faster for I/O, money is faster for doing large sums. Depending on your needs it does have an advantage over numeric. That said, I wonder if there is another answer to this question. Perhaps the functions in cash.c can be pulled out and made into external functions that can be fed an int (long) and output the desired format. That way we could use the existing int or long type but convert manually on I/O. Let people choose whether they want the simplification of the money type or the standardization allowed by just using the functions. Just a thought. -- D'Arcy J.M. Cain <darcy@druid.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
On Tue, 9 Oct 2007 11:26:16 -0400
"D'Arcy J.M. Cain" <darcy@druid.net> wrote:
> On Mon, 8 Oct 2007 20:02:56 -0700
> "Joshua D. Drake" <jd@commandprompt.com> wrote:
> > The money data type has been deprecated for years. It is completely
> > non standard and essentially duplicative of numeric/decimal. What
> > is the point?
>
> It may be deprecated (maybe not) and it may have drawbacks but it is
> not a duplication of numeric or decimal. While numeric/decimal may be
> faster for I/O, money is faster for doing large sums. Depending on
> your needs it does have an advantage over numeric.
Fair enough..
However, keep in mind that I really don't care if Money is deprecated
or not. I do care that the docs say it is, and it may not be. :)
Joshua D. Drake
>
> That said, I wonder if there is another answer to this question.
> Perhaps the functions in cash.c can be pulled out and made into
> external functions that can be fed an int (long) and output the
> desired format. That way we could use the existing int or long type
> but convert manually on I/O. Let people choose whether they want the
> simplification of the money type or the standardization allowed by
> just using the functions.
>
> Just a thought.
>
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
[Note: Cc list trimmed as everyone is probably on the list anyway] On Tue, 9 Oct 2007 09:02:09 -0700 "Joshua D. Drake" <jd@commandprompt.com> wrote: > However, keep in mind that I really don't care if Money is deprecated > or not. I do care that the docs say it is, and it may not be. :) Understood. Personally I would like to see that comment dropped but it isn't my decision. I did fix the biggest complaints in the recent change to 64 bit storage so perhaps someone can see their way clear to dropping that comment. Here is a suggested change. Index: datatype.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v retrieving revision 1.209 diff -u -p -u -r1.209 datatype.sgml --- datatype.sgml 31 Aug 2007 04:52:29 -0000 1.209 +++ datatype.sgml 9 Oct 2007 16:30:13 -0000 @@ -828,14 +828,6 @@ ALTER SEQUENCE <replaceable class="param <sect1 id="datatype-money"> <title>Monetary Types</title> - <note> - <para> - The <type>money</type> type is deprecated. Use - <type>numeric</type> or <type>decimal</type> instead, in - combination with the <function>to_char</function> function. - </para> - </note> - <para> The <type>money</type> type stores a currency amount with a fixed fractional precision; see <xref @@ -846,6 +838,15 @@ ALTER SEQUENCE <replaceable class="param Output is generally in the latter form but depends on thelocale. </para> + <para> + Due to locale changes this type may have problems with dump and + restore and care should be taken. Also, I/O is slower than using + NUMERIC or DECIMAL but internal calculations such as SUM will be + faster due to its internal storage format. Be sure to weigh all + these considerations as well as convenience when choosing between + this type and others. + </para> + <table id="datatype-money-table"> <title>Monetary Types</title> <tgroup cols="4"> -- D'Arcy J.M. Cain <darcy@druid.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
Am Dienstag, 9. Oktober 2007 schrieb D'Arcy J.M. Cain: > + Due to locale changes this type may have problems with dump and > + restore and care should be taken. With respect, this kind of advice is useless. What are the problems, when do they occur, and what should be done about them? We do know the answers to all of these questions. -- Peter Eisentraut http://developer.postgresql.org/~petere/
On Tue, 9 Oct 2007 19:02:38 +0200 Peter Eisentraut <peter_e@gmx.net> wrote: > Am Dienstag, 9. Oktober 2007 schrieb D'Arcy J.M. Cain: > > + Due to locale changes this type may have problems with dump and > > + restore and care should be taken. > > With respect, this kind of advice is useless. What are the problems, when do > they occur, and what should be done about them? We do know the answers to > all of these questions. Right. How about this: ... restore and care should be taken when dumping and reloading from different locales. To avoid problems always explicitely set your locale before both a dump and reload and make sure that they are identical. -- D'Arcy J.M. Cain <darcy@druid.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
"D'Arcy J.M. Cain" <darcy@druid.net> writes: > That said, I wonder if there is another answer to this question. > Perhaps the functions in cash.c can be pulled out and made into > external functions that can be fed an int (long) and output the desired > format. That way we could use the existing int or long type but > convert manually on I/O. Let people choose whether they want the > simplification of the money type or the standardization allowed by just > using the functions. Long term I liked the idea from a few years ago of having a "default format" which would be attached to a column just like a default collation can be attached. Then you can declare your currency columns as regular integers but mark them as being formatted as currency by default. pg_dump would presumably explicitly override the default and format the integers as plain integers and restore the default format string as part of its DDL. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
Gregory Stark <stark@enterprisedb.com> writes:
> Long term I liked the idea from a few years ago of having a "default format"
> which would be attached to a column just like a default collation can be
> attached. Then you can declare your currency columns as regular integers but
> mark them as being formatted as currency by default.
> pg_dump would presumably explicitly override the default and format the
> integers as plain integers and restore the default format string as part of
> its DDL.
At least for the case at hand, this seems a pretty horrid solution. It
could easily lead to a value that had been $1.01 being reloaded as 101 Yen,
or vice versa, neither of which would make anyone happy.
If anything I would gripe that type money is not locale-specific enough;
it doesn't have a way to prevent similar confusions between say US$
and AU$, or any two currencies using the same symbol.
The better long-term solution would be to go over to a tagged-type
arrangement, in which each value is *explicitly* marked with its
currency. This needn't be a whole lot slower than the current
arrangement --- I think D'Arcy already took the main speed hit when
he went from int4 (pass by value) to int8 (pass by reference).
regards, tom lane
On Tue, 9 Oct 2007 13:16:08 -0400 "D'Arcy J.M. Cain" <darcy@druid.net> wrote: > On Tue, 9 Oct 2007 19:02:38 +0200 > Peter Eisentraut <peter_e@gmx.net> wrote: > > Am Dienstag, 9. Oktober 2007 schrieb D'Arcy J.M. Cain: > > > + Due to locale changes this type may have problems with dump and > > > + restore and care should be taken. > > > > With respect, this kind of advice is useless. What are the problems, when do > > they occur, and what should be done about them? We do know the answers to > > all of these questions. > > Right. How about this: > > ... > restore and care should be taken when dumping and reloading from > different locales. To avoid problems always explicitely set your > locale before both a dump and reload and make sure that they are > identical. I never received a response on this. Here is the full diff with the above change. Since it is documentation and not code, is it OK to commit this now? Index: datatype.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v retrieving revision 1.211 diff -u -p -u -r1.211 datatype.sgml --- datatype.sgml 21 Oct 2007 20:04:37 -0000 1.211 +++ datatype.sgml 3 Nov 2007 12:03:55 -0000 @@ -834,14 +834,6 @@ ALTER SEQUENCE <replaceable class="param <sect1 id="datatype-money"> <title>Monetary Types</title> - <note> - <para> - The <type>money</type> type is deprecated. Use - <type>numeric</type> or <type>decimal</type> instead, in - combination with the <function>to_char</function> function. - </para> - </note> - <para> The <type>money</type> type stores a currency amount with a fixed fractional precision; see <xref @@ -852,6 +844,15 @@ ALTER SEQUENCE <replaceable class="param Output is generally in the latter form but depends on thelocale. </para> + <para> + Due to locale changes this type may have problems with dump and + restore and care should be taken when dumping and reloading from + different locales. To avoid problems always explicitely set your + locale before both a dump and reload and make sure that they are + identical. + + </para> + <table id="datatype-money-table"> <title>Monetary Types</title> <tgroup cols="4"> -- D'Arcy J.M. Cain <darcy@druid.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
"D'Arcy J.M. Cain" <darcy@druid.net> writes:
> I never received a response on this. Here is the full diff with the
> above change. Since it is documentation and not code, is it OK to
> commit this now?
The added text needs some copy-editing, I think. How about
Since the output of this data type is locale-sensitive, it may not work to load <type>money</> data into a
databasethat has a different setting of <varname>lc_monetary</>. To avoid problems, before restoring a dump make
sure<varname>lc_monetary</> has the same value as in the database that was dumped.
(Actually, the first of the two lc_monetary references should be
an xref link to the GUC variable, but I'm too lazy to type that out.)
A more direct approach to the problem might be to change pg_dump to
set lc_monetary, as it does for client_encoding ...
regards, tom lane
"Tom Lane" <tgl@sss.pgh.pa.us> writes: > A more direct approach to the problem might be to change pg_dump to > set lc_monetary, as it does for client_encoding ... It should probably note that if the machine being restored onto has a different libc it could still not be restorable even with the correct lc_monetary setting. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support!
On Sat, 03 Nov 2007 14:39:48 -0400 Tom Lane <tgl@sss.pgh.pa.us> wrote: > "D'Arcy J.M. Cain" <darcy@druid.net> writes: > > I never received a response on this. Here is the full diff with the > > above change. Since it is documentation and not code, is it OK to > > commit this now? > > The added text needs some copy-editing, I think. How about > > Since the output of this data type is locale-sensitive, it may not > work to load <type>money</> data into a database that has a different > setting of <varname>lc_monetary</>. To avoid problems, before > restoring a dump make sure <varname>lc_monetary</> has the same value > as in the database that was dumped. > > (Actually, the first of the two lc_monetary references should be > an xref link to the GUC variable, but I'm too lazy to type that out.) > > A more direct approach to the problem might be to change pg_dump to > set lc_monetary, as it does for client_encoding ... Certainly OK by me. -- D'Arcy J.M. Cain <darcy@druid.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
"D'Arcy J.M. Cain" <darcy@druid.net> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> A more direct approach to the problem might be to change pg_dump to
>> set lc_monetary, as it does for client_encoding ...
> Certainly OK by me.
Greg's objection caused me to rethink that. Doing it would be a problem
when transporting dump files across platforms: what if the appropriate
locale name is spelled differently on the new machine? We should
probably leave it in the user's hands to get this right. So the added
text could be used as I suggested, or tweaked to say that you must set
lc_monetary to something equivalent to the prior setting.
regards, tom lane
Tom Lane wrote: > Doing it would be a problem > when transporting dump files across platforms: what if the > appropriate locale name is spelled differently on the new machine? The question is which is more likely? Using a dump on a similar platform with different locale settings is fairly common, especially by accident. (And this is a problem that is easily masked if you don't run the restore with on-error-stop.) Using a dump on a platform with different locale spellings is, in my mind, rarer. And even then, if you have different locale spellings, chances are, you have semantically different locales configured. What could help is if we could invoke this only if the money type is actually used. -- Peter Eisentraut http://developer.postgresql.org/~petere/
On Sat, 03 Nov 2007 15:47:40 -0400 Tom Lane <tgl@sss.pgh.pa.us> wrote: > Greg's objection caused me to rethink that. Doing it would be a problem > when transporting dump files across platforms: what if the appropriate > locale name is spelled differently on the new machine? We should > probably leave it in the user's hands to get this right. So the added > text could be used as I suggested, or tweaked to say that you must set > lc_monetary to something equivalent to the prior setting. OK, how is this? Index: doc/src/sgml/datatype.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v retrieving revision 1.211 diff -u -p -u -r1.211 datatype.sgml --- doc/src/sgml/datatype.sgml 21 Oct 2007 20:04:37 -0000 1.211 +++ doc/src/sgml/datatype.sgml 4 Nov 2007 17:09:03 -0000 @@ -834,14 +834,6 @@ ALTER SEQUENCE <replaceable class="param <sect1 id="datatype-money"> <title>Monetary Types</title> - <note> - <para> - The <type>money</type> type is deprecated. Use - <type>numeric</type> or <type>decimal</type> instead, in - combination with the <function>to_char</function> function. - </para> - </note> - <para> The <type>money</type> type stores a currency amount with a fixed fractional precision; see <xref @@ -852,6 +844,14 @@ ALTER SEQUENCE <replaceable class="param Output is generally in the latter form but depends on thelocale. </para> + <para> + Since the output of this data type is locale-sensitive, it may not + work to load <type>money</> data into a database that has a different + setting of <varname>lc_monetary</>. To avoid problems, before + restoring a dump make sure <varname>lc_monetary</> has the same or + equivalent value as in the database that was dumped. + </para> + <table id="datatype-money-table"> <title>Monetary Types</title> <tgroup cols="4"> -- D'Arcy J.M. Cain <darcy@druid.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
D'Arcy J.M. Cain wrote: > + <para> > + Since the output of this data type is locale-sensitive, it may not > + work to load <type>money</> data into a database that has a different > + setting of <varname>lc_monetary</>. To avoid problems, before > + restoring a dump make sure <varname>lc_monetary</> has the same or > + equivalent value as in the database that was dumped. > + </para> > + How about: > + restoring a dump make sure <varname>lc_monetary</> has a value similar > + to the dumped database. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Sun, 4 Nov 2007 17:24:10 -0500 (EST) Bruce Momjian <bruce@momjian.us> wrote: > D'Arcy J.M. Cain wrote: > > + <para> > > + Since the output of this data type is locale-sensitive, it may not > > + work to load <type>money</> data into a database that has a different > > + setting of <varname>lc_monetary</>. To avoid problems, before > > + restoring a dump make sure <varname>lc_monetary</> has the same or > > + equivalent value as in the database that was dumped. > > + </para> > > + > > How about: > > > + restoring a dump make sure <varname>lc_monetary</> has a value similar > > + to the dumped database. Hmm. I think I like Tom's version better. However, since my primary goal here is to remove the deprecation I will let you guys duke it out over the additional clause. :-) -- D'Arcy J.M. Cain <darcy@druid.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
"D'Arcy J.M. Cain" <darcy@druid.net> writes:
> Hmm. I think I like Tom's version better. However, since my primary
> goal here is to remove the deprecation I will let you guys duke it out
> over the additional clause. :-)
Just pick the wording you like and commit it; we've spent more than
enough time on this already.
regards, tom lane
On Sun, 04 Nov 2007 20:38:11 -0500 Tom Lane <tgl@sss.pgh.pa.us> wrote: > "D'Arcy J.M. Cain" <darcy@druid.net> writes: > > Hmm. I think I like Tom's version better. However, since my primary > > goal here is to remove the deprecation I will let you guys duke it out > > over the additional clause. :-) > > Just pick the wording you like and commit it; we've spent more than > enough time on this already. OK. I can't seem to connect at the moment but I will commit tomorrow morning if not before. -- D'Arcy J.M. Cain <darcy@druid.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.