From: | "Greg Sabino Mullane" <greg(at)turnstep(dot)com> |
---|---|
To: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: pg_dump additional options for performance |
Date: | 2008-07-26 02:39:34 |
Message-ID: | 848d3723f7f4e3c0b0b1c597c5dc6ca8@biglumber.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
Tom Lane wrote:
> * --schema-before-data, --data-only, and --schema-after-data can be
I thought you were arguing for some better names at one point? Those seem
very confusing to me, especially "--schema-after-data". I know it means
"the parts of the schema that come after the data" but it could
also be read as other ways, including "put the schema after the data" - which
makes no sense, but the name is not exactly intuitive either. "Pre" and "Post"
at least are slightly better, IMO. How about --pre-data-schema
and --post-data-schema? Or --pre-data-section and --post-data-section?
Or (my favorites) --pre-data-commands and --post-data-commands? As the
existing docs say, "commands" are what we are generating.
> them as data, because the objects they are attached to are data. I kind
> of like the latter approach because it would create an invariant that
> comments appear in the same dump section as the object commented on.
> Thoughts?)
+1 on putting them next to the object commented on.
> And there's yet another issue here, which is that it's not entirely clear
> that the type of an object uniquely determines whether it's before or
> after data.
Wouldn't that be a problem with current dumps as well then?
> We could solve that problem by inserting a "dummy data" TOC entry where
> the data would have appeared, but this will only work in new archive
> files. With an implementation like this, pg_restore with
> --schema-before-data or --schema-after-data won't behave very nicely on a
> pre-8.4 --schema-only archive file. (Presumably it would act as though
> all the objects were "before" data.) Is that a small enough corner case
> to live with in order to gain implementation simplicity and robustness?
I'm not comfortable with corner cases for pg_restore backwards compatibility.
What exactly would happen (worse case) in that scenario?
- --
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 200807252235
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iEYEAREDAAYFAkiKjgMACgkQvJuQZxSWSsiRMACg7c/VDo9hTTjukkFFvLYI31mL
BqkAn3FfepllvVnIwX+efA5cLPlVbDd0
=V/Sv
-----END PGP SIGNATURE-----
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2008-07-26 03:23:46 | Re: [PATCHES] WITH RECUSIVE patches 0723 |
Previous Message | Alvaro Herrera | 2008-07-26 02:36:43 | Re: Review: DTrace probes (merged version) ver_03 |
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2008-07-26 03:23:46 | Re: [PATCHES] WITH RECUSIVE patches 0723 |
Previous Message | Tom Lane | 2008-07-25 23:16:24 | Re: pg_dump additional options for performance |