Patch for pg_dump: Multiple -t options and new -T option
Attached is a patch against pg_dump version 7.4.3 that permits
multiple "-t" switches so that you can select more than one table (but
less than all) to dump.
It also adds a "-T" switch (long name "--exclude-table") that says
*not* to dump a specific table. So:
pg_dump -t table1 -t table2 db
will dump table1 and table2 only, whereas:
pg_dump -T table1 -T table2 db
will dump all the tables *except* table1 and table2.
Tested briefly on my system; doesn't seem to break anything.
Regards,
David.
--
David F. Skoll <dfs@roaringpenguin.com> Roaring Penguin Software Inc.
+1 (613) 231-6599 ext. 100 http://www.roaringpenguin.com/
For CanIt technical support, please mail: support@roaringpenguin.comAttachments:
pg_dump.patchtext/plain; charset=US-ASCII; name=pg_dump.patchDownload
diff -u -r -N postgresql-7.4.3.ORIG/src/bin/pg_dump/Makefile postgresql-7.4.3/src/bin/pg_dump/Makefile
--- postgresql-7.4.3.ORIG/src/bin/pg_dump/Makefile 2003-08-08 00:52:21.000000000 -0400
+++ postgresql-7.4.3/src/bin/pg_dump/Makefile 2004-07-06 21:58:02.000000000 -0400
@@ -15,7 +15,7 @@
OBJS= pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o \
pg_backup_files.o pg_backup_null.o pg_backup_tar.o \
- dumputils.o
+ dumputils.o should_dump.o
EXTRA_OBJS = $(top_builddir)/src/backend/parser/keywords.o
diff -u -r -N postgresql-7.4.3.ORIG/src/bin/pg_dump/pg_dump.c postgresql-7.4.3/src/bin/pg_dump/pg_dump.c
--- postgresql-7.4.3.ORIG/src/bin/pg_dump/pg_dump.c 2004-05-26 14:27:23.000000000 -0400
+++ postgresql-7.4.3/src/bin/pg_dump/pg_dump.c 2004-07-06 21:58:02.000000000 -0400
@@ -139,7 +139,7 @@
/* obsolete as of 7.3: */
static Oid g_last_builtin_oid; /* value of the last builtin oid */
-static char *selectTableName = NULL; /* name of a single table to dump */
+static int partial_dump = 0; /* True if -t or -T is used */
static char *selectSchemaName = NULL; /* name of a single schema to dump */
char g_opaque_type[10]; /* name for the opaque type */
@@ -201,6 +201,7 @@
{"schema-only", no_argument, NULL, 's'},
{"superuser", required_argument, NULL, 'S'},
{"table", required_argument, NULL, 't'},
+ {"exclude-table", required_argument, NULL, 'T'},
{"password", no_argument, NULL, 'W'},
{"username", required_argument, NULL, 'U'},
{"verbose", no_argument, NULL, 'v'},
@@ -258,7 +259,7 @@
}
}
- while ((c = getopt_long(argc, argv, "abcCdDf:F:h:in:oOp:RsS:t:uU:vWxX:Z:",
+ while ((c = getopt_long(argc, argv, "abcCdDf:F:h:in:oOp:RsS:t:T:uU:vWxX:Z:",
long_options, &optindex)) != -1)
{
switch (c)
@@ -335,8 +336,14 @@
outputSuperuser = strdup(optarg);
break;
- case 't': /* Dump data for this table only */
- selectTableName = strdup(optarg);
+ case 't': /* Dump data for this table */
+ add_table_to_include_list(optarg);
+ partial_dump = 1;
+ break;
+
+ case 'T': /* Do NOT dump data for this table */
+ add_table_to_exclude_list(optarg);
+ partial_dump = 1;
break;
case 'u':
@@ -421,9 +428,9 @@
exit(1);
}
- if (outputBlobs && selectTableName != NULL)
+ if (outputBlobs && partial_dump)
{
- write_msg(NULL, "large-object output not supported for a single table\n");
+ write_msg(NULL, "large-object output not supported for a partial dump\n");
write_msg(NULL, "use a full dump instead\n");
exit(1);
}
@@ -639,7 +646,8 @@
printf(_(" -s, --schema-only dump only the schema, no data\n"));
printf(_(" -S, --superuser=NAME specify the superuser user name to use in\n"
" plain text format\n"));
- printf(_(" -t, --table=TABLE dump the named table only\n"));
+ printf(_(" -t, --table=TABLE dump the named table only (multiple -t allowed)\n"));
+ printf(_(" -T, --exclude-table=TABLE do not dump the named table (multiple -T allowed)\n"));
printf(_(" -x, --no-privileges do not dump privileges (grant/revoke)\n"));
printf(_(" -X disable-triggers, --disable-triggers\n"
" disable triggers during data-only restore\n"));
@@ -672,11 +680,11 @@
selectDumpableNamespace(NamespaceInfo *nsinfo)
{
/*
- * If a specific table is being dumped, do not dump any complete
+ * If a specific table or tables are being dumped, do not dump any complete
* namespaces. If a specific namespace is being dumped, dump just
* that namespace. Otherwise, dump all non-system namespaces.
*/
- if (selectTableName != NULL)
+ if (partial_dump)
nsinfo->dump = false;
else if (selectSchemaName != NULL)
{
@@ -707,8 +715,7 @@
tbinfo->dump = false;
if (tbinfo->relnamespace->dump)
tbinfo->dump = true;
- else if (selectTableName != NULL &&
- strcmp(tbinfo->relname, selectTableName) == 0)
+ else if (should_dump_table(tbinfo->relname))
{
/* If both -s and -t specified, must match both to dump */
if (selectSchemaName == NULL)
@@ -2317,7 +2324,10 @@
* If the user is attempting to dump a specific table, check to ensure
* that the specified table actually exists. (This is a bit simplistic
* since we don't fully check the combination of -n and -t switches.)
+ *
+ * This check is DISABLED with support for multiple -t swictches --dfs
*/
+#if 0
if (selectTableName)
{
for (i = 0; i < ntups; i++)
@@ -2332,6 +2342,7 @@
exit_nicely();
}
}
+#endif
PQclear(res);
destroyPQExpBuffer(query);
diff -u -r -N postgresql-7.4.3.ORIG/src/bin/pg_dump/pg_dump.h postgresql-7.4.3/src/bin/pg_dump/pg_dump.h
--- postgresql-7.4.3.ORIG/src/bin/pg_dump/pg_dump.h 2003-08-08 00:52:21.000000000 -0400
+++ postgresql-7.4.3/src/bin/pg_dump/pg_dump.h 2004-07-06 21:58:02.000000000 -0400
@@ -235,4 +235,9 @@
const bool schemaOnly, const bool dataOnly);
extern void dumpIndexes(Archive *fout, TableInfo *tbinfo, int numTables);
+/* Defined in should_dump.c */
+extern int add_table_to_exclude_list(char const *name);
+extern int add_table_to_include_list(char const *name);
+extern int should_dump_table(char const *name);
+
#endif /* PG_DUMP_H */
diff -u -r -N postgresql-7.4.3.ORIG/src/bin/pg_dump/should_dump.c postgresql-7.4.3/src/bin/pg_dump/should_dump.c
--- postgresql-7.4.3.ORIG/src/bin/pg_dump/should_dump.c 1969-12-31 19:00:00.000000000 -0500
+++ postgresql-7.4.3/src/bin/pg_dump/should_dump.c 2004-07-06 21:58:02.000000000 -0400
@@ -0,0 +1,73 @@
+#include "pg_dump.h"
+#include <string.h>
+#include <stdlib.h>
+
+/* Routines for keeping track of which tables should be dumped, so
+ pg_dump can take multiple "-t" options
+
+ Copyright 2004 Roaring Penguin Software Inc.
+
+ This file may be distributed under the same terms as the PostgreSQL
+ database system */
+
+typedef struct name_list_t {
+ struct name_list_t *next;
+ char const *name;
+} name_list;
+
+static name_list *tables_to_include = NULL;
+static name_list *tables_to_exclude = NULL;
+
+/* Add a name to one of the lists */
+static int
+add_name_to_list(name_list **list, char const *name)
+{
+ name_list *node = malloc(sizeof(name_list));
+ if (!node) return -1;
+ node->name = strdup(name);
+ if (!node->name) {
+ free(node);
+ return -1;
+ }
+ node->next = *list;
+ *list = node;
+ return 0;
+}
+
+/* Return true if a node is on a list, false otherwise */
+static int
+name_is_on_list(name_list *list, char const *name)
+{
+ while(list) {
+ if (!strcmp(name, list->name)) {
+ return 1;
+ }
+ list = list->next;
+ }
+ return 0;
+}
+
+/* Add a table to the exclude list */
+int
+add_table_to_exclude_list(char const *name) {
+ return add_name_to_list(&tables_to_exclude, name);
+}
+
+/* Add a table to the include list */
+int
+add_table_to_include_list(char const *name) {
+ return add_name_to_list(&tables_to_include, name);
+}
+
+/* Should we dump a table? */
+int
+should_dump_table(char const *name)
+{
+ if (tables_to_exclude && name_is_on_list(tables_to_exclude, name)) {
+ return 0;
+ }
+ if (tables_to_include && !name_is_on_list(tables_to_include, name)) {
+ return 0;
+ }
+ return 1;
+}
Does anyone have opinions on including this in 7.5? I see it first
appeared on July 6, six days after feature freeze.
---------------------------------------------------------------------------
David F. Skoll wrote:
Attached is a patch against pg_dump version 7.4.3 that permits
multiple "-t" switches so that you can select more than one table (but
less than all) to dump.It also adds a "-T" switch (long name "--exclude-table") that says
*not* to dump a specific table. So:pg_dump -t table1 -t table2 db
will dump table1 and table2 only, whereas:
pg_dump -T table1 -T table2 db
will dump all the tables *except* table1 and table2.
Tested briefly on my system; doesn't seem to break anything.
Regards,
David.
-- David F. Skoll <dfs@roaringpenguin.com> Roaring Penguin Software Inc. +1 (613) 231-6599 ext. 100 http://www.roaringpenguin.com/ For CanIt technical support, please mail: support@roaringpenguin.com
Content-Description:
[ Attachment, skipping... ]
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073I see one vote in favor of its inclusion on the grounds it is a bug not
to support multiple -t parameters. However, is someone objects I will
have to hold it for 7.6. It needs SGML doc additions which I will do
myself.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---------------------------------------------------------------------------
David F. Skoll wrote:
Attached is a patch against pg_dump version 7.4.3 that permits
multiple "-t" switches so that you can select more than one table (but
less than all) to dump.It also adds a "-T" switch (long name "--exclude-table") that says
*not* to dump a specific table. So:pg_dump -t table1 -t table2 db
will dump table1 and table2 only, whereas:
pg_dump -T table1 -T table2 db
will dump all the tables *except* table1 and table2.
Tested briefly on my system; doesn't seem to break anything.
Regards,
David.
-- David F. Skoll <dfs@roaringpenguin.com> Roaring Penguin Software Inc. +1 (613) 231-6599 ext. 100 http://www.roaringpenguin.com/ For CanIt technical support, please mail: support@roaringpenguin.com
Content-Description:
[ Attachment, skipping... ]
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
I see one vote in favor of its inclusion on the grounds it is a bug not
to support multiple -t parameters. However, is someone objects I will
have to hold it for 7.6. It needs SGML doc additions which I will do
myself.
Weeeeell, I guess I'm against it based on the rules of feature freeze,
even though it would be really useful for me :(
I don't see how it's a "bug" to not support multiple parameters thought
- that's really scraping the bottom of the barrel...
Chris
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
Weeeeell, I guess I'm against it based on the rules of feature freeze,
even though it would be really useful for me :(
It would have been a lot easier to approve it if it'd arrived on June 30
rather than July 6 :-(. However, I do believe that David originally
submitted a slightly-too-late version of this in the previous release
cycle, so maybe we could cut him a little slack and pretend this is a
mistakenly-forgotten patch that we held over from 7.4.
Note I haven't actually *read* the patch and so take no position on
whether it does what it claims to. But if someone else will read/test
it and give it a favorable report, then I'm inclined to approve it.
I'm quite sure we'd agreed in principle to allow multiple -t values.
(A negative -T switch is another matter --- that part maybe needs
more discussion.)
regards, tom lane
Weeeeell, I guess I'm against it based on the rules of feature freeze,
even though it would be really useful for me :(It would have been a lot easier to approve it if it'd arrived on June 30
rather than July 6 :-(. However, I do believe that David originally
submitted a slightly-too-late version of this in the previous release
cycle, so maybe we could cut him a little slack and pretend this is a
mistakenly-forgotten patch that we held over from 7.4.
Yes, the reason it would be nice for me is that currently if you want to
dump two specific, related tables from your db, there's no way to do it
with pg_dump within the one transactions (ie. maintaining integrity). I
guess I'm in favour of -t -t but not -T depending on the complexity of
it. I'll review the patch if you like.
Chris
Yes, the reason it would be nice for me is that currently if you want to
dump two specific, related tables from your db, there's no way to do it
with pg_dump within the one transactions (ie. maintaining integrity). I
guess I'm in favour of -t -t but not -T depending on the complexity of
it. I'll review the patch if you like.
One problem with this patch is that there's no way to dump multiple
tables in different schemas. Does this matter? It's a bit
non-orthogonal...
Chris
Tom Lane said:
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
Weeeeell, I guess I'm against it based on the rules of feature freeze,
even though it would be really useful for me :(It would have been a lot easier to approve it if it'd arrived on June
30 rather than July 6 :-(. However, I do believe that David originally
submitted a slightly-too-late version of this in the previous release
cycle, so maybe we could cut him a little slack and pretend this is a
mistakenly-forgotten patch that we held over from 7.4.Note I haven't actually *read* the patch and so take no position on
whether it does what it claims to. But if someone else will read/test
it and give it a favorable report, then I'm inclined to approve it. I'm
quite sure we'd agreed in principle to allow multiple -t values. (A
negative -T switch is another matter --- that part maybe needs
more discussion.)
I entirely agree. Feature freeze has been said to be slightly porous, and
this is a change with relatively low impact/risk and significant benefit.
Let's not be overly rulebound.
cheers
andrew
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
One problem with this patch is that there's no way to dump multiple
tables in different schemas. Does this matter? It's a bit
non-orthogonal...
Yeah. With the combination of -n and -t you can pull a specific table,
but as soon as you allow either switch to be multiple you've got an
inexact tool.
I had thought of allowing -t to be schema.table but I'm worried about
backwards-compatibility issues. In particular, since we don't support
SQL-style quoting in -t arguments, how could one then select a table
name that actually contains a dot? Or should we just write off that
case as "stupidity is its own reward"? It would also be good to not
foreclose the possibility of wild-card matching patterns in these
switches in future.
(BTW, does the patch handle multiple -n switches?)
regards, tom lane
On Tue, 20 Jul 2004, Tom Lane wrote:
(BTW, does the patch handle multiple -n switches?)
No, it doesn't. I can look into that if you like. The patch was
entirely to satisfy a need some of our customers have. The -T switch
does fill a real need for our customers; our product has a couple of tables
that aren't critical if they aren't backed up, but as the product evolves,
we occasionally add more tables. So it's easier to use a -T switch to
say what *not* to back up, than multiple -t switches to say what to back up.
Regards,
David.
Tom Lane wrote:
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
Weeeeell, I guess I'm against it based on the rules of feature freeze,
even though it would be really useful for me :(It would have been a lot easier to approve it if it'd arrived on June 30
rather than July 6 :-(. However, I do believe that David originally
submitted a slightly-too-late version of this in the previous release
cycle, so maybe we could cut him a little slack and pretend this is a
mistakenly-forgotten patch that we held over from 7.4.
Yes, I do see one from 7.4 but it was submitted by someone else:
---------------------------------------------------------------------------
Message 179/231 Andreas Joseph Krogh
Oct 1, 2003 04:00:08 pm +0200
Organization: OfficeNet AS
To: pgsql-hackers@postgresql.org
Subject: [HACKERS] Patch for allowing multiple -t <table-name> options
for pg_dump
Date: Wed, 1 Oct 2003 16:00:08 +0200
This si my first look at the pg-code, so it may not comply with the
coding-standards. I haven't coded in C for a while either, so if someone
finds a better way to implement this, go ahead, but this patch works for
me
with 7.4beta3.
http://home.officenet.no/~andreak/pg_dump.c.diff
comments are welcome.
If it's ok, I'll remove my debuging statements and provide a cleaner
patch.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073David F. Skoll wrote:
On Tue, 20 Jul 2004, Tom Lane wrote:
(BTW, does the patch handle multiple -n switches?)
No, it doesn't. I can look into that if you like. The patch was
entirely to satisfy a need some of our customers have. The -T switch
does fill a real need for our customers; our product has a couple of tables
that aren't critical if they aren't backed up, but as the product evolves,
we occasionally add more tables. So it's easier to use a -T switch to
say what *not* to back up, than multiple -t switches to say what to back up.
Ah, I see in TODO:
* Allow pg_dump to use multiple -t and -n switches
so the problem with lack of multiple -n parameters was already known.
Should we allow -n to affect subsequent -t parameters, so:
-n schema1 -t tab1 -n schema2 -t tab2
does schema1.tab1 and schema2.tab2?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073No, it doesn't. I can look into that if you like. The patch was
entirely to satisfy a need some of our customers have. The -T switch
does fill a real need for our customers; our product has a couple of tables
that aren't critical if they aren't backed up, but as the product evolves,
we occasionally add more tables. So it's easier to use a -T switch to
say what *not* to back up, than multiple -t switches to say what to back up.
Well, since you wrote the patch, you'd be better off munging it. Read
Tom's comments and see what you can come up with. There's been no
decision made yet though on what changes to make however.
Chris
On Wed, 21 Jul 2004, Christopher Kings-Lynne wrote:
No, it doesn't. I can look into that if you like. The patch was
entirely to satisfy a need some of our customers have. The -T switch
does fill a real need for our customers; our product has a couple of tables
that aren't critical if they aren't backed up, but as the product evolves,
we occasionally add more tables. So it's easier to use a -T switch to
say what *not* to back up, than multiple -t switches to say what to back up.Well, since you wrote the patch, you'd be better off munging it. Read
Tom's comments and see what you can come up with. There's been no
decision made yet though on what changes to make however.
I'd also move the should_dump.c file into an existing file and make sure
the patch is against CVS HEAD, not 7.4.3.
Also, there's a copyright statement at the top, retaining copyright with
the author. Does anyone have an issue with that?
Gavin
Gavin Sherry wrote:
On Wed, 21 Jul 2004, Christopher Kings-Lynne wrote:
No, it doesn't. I can look into that if you like. The patch was
entirely to satisfy a need some of our customers have. The -T switch
does fill a real need for our customers; our product has a couple of tables
that aren't critical if they aren't backed up, but as the product evolves,
we occasionally add more tables. So it's easier to use a -T switch to
say what *not* to back up, than multiple -t switches to say what to back up.Well, since you wrote the patch, you'd be better off munging it. Read
Tom's comments and see what you can come up with. There's been no
decision made yet though on what changes to make however.I'd also move the should_dump.c file into an existing file and make sure
the patch is against CVS HEAD, not 7.4.3.
Agreed.
Also, there's a copyright statement at the top, retaining copyright with
the author. Does anyone have an issue with that?
Yes, no need for it. We discourage that.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
At 12:59 PM 21/07/2004, Bruce Momjian wrote:
Yes, no need for it. We discourage that.
Might be polite, not to mention legally required, to check with the author
of the patch first.
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 03 5330 3172 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp.mit.edu:11371 |/
Philip Warner wrote:
At 12:59 PM 21/07/2004, Bruce Momjian wrote:
Yes, no need for it. We discourage that.
Might be polite, not to mention legally required, to check with the author
of the patch first.
To be clear, we will ask the author if we can remove it, and if they say
no, we will reject the patch.
That's not a polite way to put it, but it is our procedure.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Hi,
This is a response to several messages:
1) Copyright notice: I have no problem having this removed, although it
would be nice to credit me somewhere in a comment.
2) I put most of the code in a separate file so that if the patch is
rejected, it's easy for me to maintain a forked copy. If the patch is
accepted, obviously it can be integrated into an existing file.
3) Multiple -n options: We need to figure out how this would work, and make
it non-surprising. Some ideas:
pg_dump -t t1 -n s2 -t t2 -t t3 -n s4 -t t5
What does that do? My guess is:
- Dump table t1 in any schema
- Dump tables t2 and t3 in schema s2
- Dump table t5 in schema s4
So now the position of the options matters! That might surprise people,
because:
pg_dump -s s1 -t t2
is no longer the same as:
pg_dump -t t2 -n s1
What about:
pg_dump -t t1 -n s2
Should that dump table t1 in any schema, and any table in schema s2?
If we can nail down the semantics, I can implement the patch. The
code is very simple.
4) The -T option (and, one assumes, a corresponding -N option)
If the -T option is considered unknown/risky and would prevent the patch
from going in, we can drop it for now.
Regards,
David.
David F. Skoll wrote:
Hi,
This is a response to several messages:
1) Copyright notice: I have no problem having this removed, although it
would be nice to credit me somewhere in a comment.
We credit in the commit message, and in the release notes so it will
always be seen.
2) I put most of the code in a separate file so that if the patch is
rejected, it's easy for me to maintain a forked copy. If the patch is
accepted, obviously it can be integrated into an existing file.
OK. Makes sense.
3) Multiple -n options: We need to figure out how this would work, and make
it non-surprising. Some ideas:pg_dump -t t1 -n s2 -t t2 -t t3 -n s4 -t t5
What does that do? My guess is:
- Dump table t1 in any schema
- Dump tables t2 and t3 in schema s2
- Dump table t5 in schema s4So now the position of the options matters! That might surprise people,
because:pg_dump -s s1 -t t2
is no longer the same as:
pg_dump -t t2 -n s1
What about:
pg_dump -t t1 -n s2
Should that dump table t1 in any schema, and any table in schema s2?
If we can nail down the semantics, I can implement the patch. The
code is very simple.
Even though I suggested it, I am afraid this is just too confusing an API.
And I can't think of another one. :-(
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073On Wed, 21 Jul 2004, Bruce Momjian wrote:
Even though I suggested it, I am afraid this is just too confusing an API.
How about this:
pg_dump -t t1 -- Dump table t1 in any schema
pg_dump -n s1 -- Dump all of schema s1
pg_dump -t t1 -n s1 -- Dump t1 in s1
pg_dump -t t1 -t t2 -n s1 -- Dump s1.t1 and s1.t2
pg_dump -t t1 -t t2 -n s1 -n s2 -- Dump s1.t1, s1.t2, s2.t1 and s2.t2
Basically, no "-t" option means dump all tables. No "-n" option
means dump all schemas. If any "-t" or "-n" options are present,
then we only dump the specified tables/schemas. We also probably
should not warn about missing tables, because it's likely that the
full cartesian product of schemas and tables won't exist.
And we nuke the -T and -N options.
Regards,
David.
"David F. Skoll" <dfs@roaringpenguin.com> writes:
How about this:
pg_dump -t t1 -- Dump table t1 in any schema
pg_dump -n s1 -- Dump all of schema s1
pg_dump -t t1 -n s1 -- Dump t1 in s1
pg_dump -t t1 -t t2 -n s1 -- Dump s1.t1 and s1.t2
pg_dump -t t1 -t t2 -n s1 -n s2 -- Dump s1.t1, s1.t2, s2.t1 and s2.t2
Why not
pg_dump -t t1 -- Dump table t1 in any schema
pg_dump -n s1 -- Dump all of schema s1
pg_dump -t s1.t1 -- Dump t1 in s1
pg_dump -t s1.t1 -t s2.t2 -- Dump s1.t1 and s2.t2
pg_dump -t t1 -t t2 -n s1 -n s2 -- Dump s1.t1, s1.t2, s2.t1 and s2.t2
That is, the rules are:
- if any -t switches appear, only tables matching (any one of)
those switches are dumped
- if any -n switches appear, only objects in (any one of)
those schemas are dumped
- a -t switch can be name only or schema.name
The cross-product semantics you're proposing can't implement my fourth
example.
I really dislike the idea of switch ordering making a difference...
We also probably should not warn about missing tables, because it's
likely that the full cartesian product of schemas and tables won't
exist.
Agreed. If any -t or -n switches appear, then warn only if *no* objects
get selected.
regards, tom lane
On Wed, 21 Jul 2004, Tom Lane wrote:
pg_dump -t s1.t1 -t s2.t2 -- Dump s1.t1 and s2.t2
That's a good idea, but then it's questionable whether we need the -n
switch at all. It might be simpler to extend the -t switch to
accept:
pg-dump -t 's1.*'
rather than using a -n switch. Of course, that breaks
backward-compatibility.
Regards,
David.
"David F. Skoll" <dfs@roaringpenguin.com> writes:
On Wed, 21 Jul 2004, Tom Lane wrote:
pg_dump -t s1.t1 -t s2.t2 -- Dump s1.t1 and s2.t2
That's a good idea, but then it's questionable whether we need the -n
switch at all.
Sure we do --- for backwards compatibility if nothing else.
It might be simpler to extend the -t switch to accept:
pg-dump -t 's1.*'
That would not be the same thing --- that would mean to dump *only tables*
from s1, rather than objects of all types. Anyway, I think it's a bit
late in this cycle to be proposing to implement wild-card matching.
Maybe for next time someone can do that, but for 7.5 I think we should
limit ourselves to cleaning up any design flaws of the already-submitted
patch.
regards, tom lane
Is anyone working on this patch?
---------------------------------------------------------------------------
Tom Lane wrote:
"David F. Skoll" <dfs@roaringpenguin.com> writes:
On Wed, 21 Jul 2004, Tom Lane wrote:
pg_dump -t s1.t1 -t s2.t2 -- Dump s1.t1 and s2.t2
That's a good idea, but then it's questionable whether we need the -n
switch at all.Sure we do --- for backwards compatibility if nothing else.
It might be simpler to extend the -t switch to accept:
pg-dump -t 's1.*'That would not be the same thing --- that would mean to dump *only tables*
from s1, rather than objects of all types. Anyway, I think it's a bit
late in this cycle to be proposing to implement wild-card matching.
Maybe for next time someone can do that, but for 7.5 I think we should
limit ourselves to cleaning up any design flaws of the already-submitted
patch.regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073I just got an autoreply from David stating he will be away until August
9 if we want this functionality we have to code it ourselves. If not it
can wait until the next major release.
If anyone wants the original patch I can supply it.
---------------------------------------------------------------------------
Tom Lane wrote:
"David F. Skoll" <dfs@roaringpenguin.com> writes:
On Wed, 21 Jul 2004, Tom Lane wrote:
pg_dump -t s1.t1 -t s2.t2 -- Dump s1.t1 and s2.t2
That's a good idea, but then it's questionable whether we need the -n
switch at all.Sure we do --- for backwards compatibility if nothing else.
It might be simpler to extend the -t switch to accept:
pg-dump -t 's1.*'That would not be the same thing --- that would mean to dump *only tables*
from s1, rather than objects of all types. Anyway, I think it's a bit
late in this cycle to be proposing to implement wild-card matching.
Maybe for next time someone can do that, but for 7.5 I think we should
limit ourselves to cleaning up any design flaws of the already-submitted
patch.regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Bruce Momjian <pgman@candle.pha.pa.us> writes:
I just got an autoreply from David stating he will be away until August
9 if we want this functionality we have to code it ourselves. If not it
can wait until the next major release.
It can wait --- it was submitted after feature freeze anyway, and we
certainly have more than enough other things to do in the next couple days.
regards, tom lane
This has been saved for the 7.6 release:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
---------------------------------------------------------------------------
Tom Lane wrote:
"David F. Skoll" <dfs@roaringpenguin.com> writes:
On Wed, 21 Jul 2004, Tom Lane wrote:
pg_dump -t s1.t1 -t s2.t2 -- Dump s1.t1 and s2.t2
That's a good idea, but then it's questionable whether we need the -n
switch at all.Sure we do --- for backwards compatibility if nothing else.
It might be simpler to extend the -t switch to accept:
pg-dump -t 's1.*'That would not be the same thing --- that would mean to dump *only tables*
from s1, rather than objects of all types. Anyway, I think it's a bit
late in this cycle to be proposing to implement wild-card matching.
Maybe for next time someone can do that, but for 7.5 I think we should
limit ourselves to cleaning up any design flaws of the already-submitted
patch.regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073I just got an autoreply from David stating he will be away until August
9 if we want this functionality we have to code it ourselves. If not it
can wait until the next major release.It can wait --- it was submitted after feature freeze anyway, and we
certainly have more than enough other things to do in the next couple days.
I have a plan to allow pg_dump to dump any object in the next version -
i suspect these two ideas will need reconciliation.
Chris
TODO item?
---------------------------------------------------------------------------
Christopher Kings-Lynne wrote:
I just got an autoreply from David stating he will be away until August
9 if we want this functionality we have to code it ourselves. If not it
can wait until the next major release.It can wait --- it was submitted after feature freeze anyway, and we
certainly have more than enough other things to do in the next couple days.I have a plan to allow pg_dump to dump any object in the next version -
i suspect these two ideas will need reconciliation.Chris
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Perhaps. I was also thinking that maybe it's time to combine pg_dumpall
and pg_dump into a single utility. At the moment, I can't see how
pg_dumpall can ever have a -Fc option, since it will be messy to
interact with the pg_dump processes.
I was thinking a pg_export utility that can output to a range of other
databases SQL formats would also be a good idea. It would share about
90% of the pg_dump code, but I'm trying to think of how to avoid
duplicating the code.
How about we have a whole pg_dump/dumpall/restore/backup section in the
TODO file?
Chris
Bruce Momjian wrote:
Show quoted text
TODO item?
---------------------------------------------------------------------------
Christopher Kings-Lynne wrote:
I just got an autoreply from David stating he will be away until August
9 if we want this functionality we have to code it ourselves. If not it
can wait until the next major release.It can wait --- it was submitted after feature freeze anyway, and we
certainly have more than enough other things to do in the next couple days.I have a plan to allow pg_dump to dump any object in the next version -
i suspect these two ideas will need reconciliation.Chris
Yes, shoot over that the section should contain.
---------------------------------------------------------------------------
Christopher Kings-Lynne wrote:
Perhaps. I was also thinking that maybe it's time to combine pg_dumpall
and pg_dump into a single utility. At the moment, I can't see how
pg_dumpall can ever have a -Fc option, since it will be messy to
interact with the pg_dump processes.I was thinking a pg_export utility that can output to a range of other
databases SQL formats would also be a good idea. It would share about
90% of the pg_dump code, but I'm trying to think of how to avoid
duplicating the code.How about we have a whole pg_dump/dumpall/restore/backup section in the
TODO file?Chris
Bruce Momjian wrote:
TODO item?
---------------------------------------------------------------------------
Christopher Kings-Lynne wrote:
I just got an autoreply from David stating he will be away until August
9 if we want this functionality we have to code it ourselves. If not it
can wait until the next major release.It can wait --- it was submitted after feature freeze anyway, and we
certainly have more than enough other things to do in the next couple days.I have a plan to allow pg_dump to dump any object in the next version -
i suspect these two ideas will need reconciliation.Chris
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Bruce Momjian <pgman@candle.pha.pa.us> writes:
TODO item?
On that note several prior conversations I had here ended with WIBNI
conclusions that really ought to be TODO items, in my humble opinion. Two come
to mind off the top of my head resulting in:
. "SELECT * FROM x JOIN y USING (b) WHERE a=?" could use an index on y(a,b)
since for a constant value of "a" the index traversal would be effectively
equivalent just be "b". This could result in an efficient merge join
avoiding an unnecessary sort.
. The semantics for row-value expressions is wrong. (a,b) < (x,y) should be
true if a<x or if a=x and b<y. Currently it expands to a<x and b<y.
. Fix row-value expression handling to not depend on the operator names and
instead use btree access method strategy values instead, allowing row-value
expressions on other operators with <,=,> behaviour (ie btree indexable
behaviour).
. Allow multi-column indexes to be used to optimize row-value expressions. Ie,
allow a btree index on a,b to be used to execute an expression like (a,b) <
(x,y).
--
greg
Greg Stark wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
TODO item?
On that note several prior conversations I had here ended with WIBNI
conclusions that really ought to be TODO items, in my humble opinion. Two come
to mind off the top of my head resulting in:. "SELECT * FROM x JOIN y USING (b) WHERE a=?" could use an index on y(a,b)
since for a constant value of "a" the index traversal would be effectively
equivalent just be "b". This could result in an efficient merge join
avoiding an unnecessary sort.. The semantics for row-value expressions is wrong. (a,b) < (x,y) should be
true if a<x or if a=x and b<y. Currently it expands to a<x and b<y.. Fix row-value expression handling to not depend on the operator names and
instead use btree access method strategy values instead, allowing row-value
expressions on other operators with <,=,> behaviour (ie btree indexable
behaviour).. Allow multi-column indexes to be used to optimize row-value expressions. Ie,
allow a btree index on a,b to be used to execute an expression like (a,b) <
(x,y).
I have not heard of any of those so I have not been actively excluding
them from the TODO list. However, I need someone with optimizer
experience to make a recommendation.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Bruce Momjian <pgman@candle.pha.pa.us> writes:
. Allow multi-column indexes to be used to optimize row-value expressions. Ie,
allow a btree index on a,b to be used to execute an expression like (a,b) <
(x,y).I have not heard of any of those so I have not been actively excluding
them from the TODO list. However, I need someone with optimizer
experience to make a recommendation.
Well the row-value expression stuff comes out of a discussion just this week.
You could check messages on pgsql-performance with the subject "[PERFORM] best
way to fetch next/prev record based on index". In particular Tom's messages
from Wednesday the 28th might be relevant.
The optimization in the first one came up in a conversation that was quite a
bit older. I don't have that thread saved. It seems like an obvious
optimization if it can be done efficiently.
--
greg
OK, everything for pg_dump TODO I can think of:
pg_dump/pg_dumpall/pg_restore
* Add dumping of comments on composite type columns
* Add dumping of comments on index columns
* Replace crude DELETE FROM way of dumping cleaning of users and groups
with separate DROP commands
* Add dumping and restoring of LOB comments
* Stop dumping CASCADE on DROP TYPE commands in clean mode
* Add full object name to the tag field. eg. for operators we need
'=(integer, integer)', instead of just '='.
* Add pg_dumpall custom format dumps. This is probably best done by:
* Combining pg_dump and pg_dumpall into a single binary
* Export to other database (eg. Oracle, MySQL and DB2) formats
I'm hopefully getting the first 4 in for 8.0 release... The full names
in tags one should be done really as well at some point.
Anyone got anything else?
Chris
Bruce Momjian wrote:
Show quoted text
Yes, shoot over that the section should contain.
---------------------------------------------------------------------------
Christopher Kings-Lynne wrote:
Perhaps. I was also thinking that maybe it's time to combine pg_dumpall
and pg_dump into a single utility. At the moment, I can't see how
pg_dumpall can ever have a -Fc option, since it will be messy to
interact with the pg_dump processes.I was thinking a pg_export utility that can output to a range of other
databases SQL formats would also be a good idea. It would share about
90% of the pg_dump code, but I'm trying to think of how to avoid
duplicating the code.How about we have a whole pg_dump/dumpall/restore/backup section in the
TODO file?Chris
Bruce Momjian wrote:
TODO item?
---------------------------------------------------------------------------
Christopher Kings-Lynne wrote:
I just got an autoreply from David stating he will be away until August
9 if we want this functionality we have to code it ourselves. If not it
can wait until the next major release.It can wait --- it was submitted after feature freeze anyway, and we
certainly have more than enough other things to do in the next couple days.I have a plan to allow pg_dump to dump any object in the next version -
i suspect these two ideas will need reconciliation.Chris
And I forgot to add:
* Allow dumping/restoring of any number of specific objects and types
Chris
Christopher Kings-Lynne wrote:
Show quoted text
OK, everything for pg_dump TODO I can think of:
pg_dump/pg_dumpall/pg_restore
* Add dumping of comments on composite type columns
* Add dumping of comments on index columns
* Replace crude DELETE FROM way of dumping cleaning of users and groups
with separate DROP commands
* Add dumping and restoring of LOB comments
* Stop dumping CASCADE on DROP TYPE commands in clean mode
* Add full object name to the tag field. eg. for operators we need
'=(integer, integer)', instead of just '='.
* Add pg_dumpall custom format dumps. This is probably best done by:
* Combining pg_dump and pg_dumpall into a single binary
* Export to other database (eg. Oracle, MySQL and DB2) formatsI'm hopefully getting the first 4 in for 8.0 release... The full names
in tags one should be done really as well at some point.Anyone got anything else?
Chris
Bruce Momjian wrote:
Yes, shoot over that the section should contain.
---------------------------------------------------------------------------
Christopher Kings-Lynne wrote:
Perhaps. I was also thinking that maybe it's time to combine
pg_dumpall and pg_dump into a single utility. At the moment, I can't
see how pg_dumpall can ever have a -Fc option, since it will be messy
to interact with the pg_dump processes.I was thinking a pg_export utility that can output to a range of
other databases SQL formats would also be a good idea. It would
share about 90% of the pg_dump code, but I'm trying to think of how
to avoid duplicating the code.How about we have a whole pg_dump/dumpall/restore/backup section in
the TODO file?Chris
Bruce Momjian wrote:
TODO item?
---------------------------------------------------------------------------
Christopher Kings-Lynne wrote:
I just got an autoreply from David stating he will be away until
August
9 if we want this functionality we have to code it ourselves. If
not it
can wait until the next major release.It can wait --- it was submitted after feature freeze anyway, and we
certainly have more than enough other things to do in the next
couple days.I have a plan to allow pg_dump to dump any object in the next
version - i suspect these two ideas will need reconciliation.Chris
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
Do you want any of these added to the TODO?
---------------------------------------------------------------------------
Christopher Kings-Lynne wrote:
And I forgot to add:
* Allow dumping/restoring of any number of specific objects and types
Chris
Christopher Kings-Lynne wrote:
OK, everything for pg_dump TODO I can think of:
pg_dump/pg_dumpall/pg_restore
* Add dumping of comments on composite type columns
* Add dumping of comments on index columns
* Replace crude DELETE FROM way of dumping cleaning of users and groups
with separate DROP commands
* Add dumping and restoring of LOB comments
* Stop dumping CASCADE on DROP TYPE commands in clean mode
* Add full object name to the tag field. eg. for operators we need
'=(integer, integer)', instead of just '='.
* Add pg_dumpall custom format dumps. This is probably best done by:
* Combining pg_dump and pg_dumpall into a single binary
* Export to other database (eg. Oracle, MySQL and DB2) formatsI'm hopefully getting the first 4 in for 8.0 release... The full names
in tags one should be done really as well at some point.Anyone got anything else?
Chris
Bruce Momjian wrote:
Yes, shoot over that the section should contain.
---------------------------------------------------------------------------
Christopher Kings-Lynne wrote:
Perhaps. I was also thinking that maybe it's time to combine
pg_dumpall and pg_dump into a single utility. At the moment, I can't
see how pg_dumpall can ever have a -Fc option, since it will be messy
to interact with the pg_dump processes.I was thinking a pg_export utility that can output to a range of
other databases SQL formats would also be a good idea. It would
share about 90% of the pg_dump code, but I'm trying to think of how
to avoid duplicating the code.How about we have a whole pg_dump/dumpall/restore/backup section in
the TODO file?Chris
Bruce Momjian wrote:
TODO item?
---------------------------------------------------------------------------
Christopher Kings-Lynne wrote:
I just got an autoreply from David stating he will be away until
August
9 if we want this functionality we have to code it ourselves. If
not it
can wait until the next major release.It can wait --- it was submitted after feature freeze anyway, and we
certainly have more than enough other things to do in the next
couple days.I have a plan to allow pg_dump to dump any object in the next
version - i suspect these two ideas will need reconciliation.Chris
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Yep, a whole section for pg_dump features and bugs would be nice.
Bruce Momjian wrote:
Show quoted text
Do you want any of these added to the TODO?
---------------------------------------------------------------------------
Christopher Kings-Lynne wrote:
And I forgot to add:
* Allow dumping/restoring of any number of specific objects and types
Chris
Christopher Kings-Lynne wrote:
OK, everything for pg_dump TODO I can think of:
pg_dump/pg_dumpall/pg_restore
* Add dumping of comments on composite type columns
* Add dumping of comments on index columns
* Replace crude DELETE FROM way of dumping cleaning of users and groups
with separate DROP commands
* Add dumping and restoring of LOB comments
* Stop dumping CASCADE on DROP TYPE commands in clean mode
* Add full object name to the tag field. eg. for operators we need
'=(integer, integer)', instead of just '='.
* Add pg_dumpall custom format dumps. This is probably best done by:
* Combining pg_dump and pg_dumpall into a single binary
* Export to other database (eg. Oracle, MySQL and DB2) formatsI'm hopefully getting the first 4 in for 8.0 release... The full names
in tags one should be done really as well at some point.Anyone got anything else?
Chris
Bruce Momjian wrote:
Yes, shoot over that the section should contain.
---------------------------------------------------------------------------
Christopher Kings-Lynne wrote:
Perhaps. I was also thinking that maybe it's time to combine
pg_dumpall and pg_dump into a single utility. At the moment, I can't
see how pg_dumpall can ever have a -Fc option, since it will be messy
to interact with the pg_dump processes.I was thinking a pg_export utility that can output to a range of
other databases SQL formats would also be a good idea. It would
share about 90% of the pg_dump code, but I'm trying to think of how
to avoid duplicating the code.How about we have a whole pg_dump/dumpall/restore/backup section in
the TODO file?Chris
Bruce Momjian wrote:
TODO item?
---------------------------------------------------------------------------
Christopher Kings-Lynne wrote:
I just got an autoreply from David stating he will be away until
August
9 if we want this functionality we have to code it ourselves. If
not it
can wait until the next major release.It can wait --- it was submitted after feature freeze anyway, and we
certainly have more than enough other things to do in the next
couple days.I have a plan to allow pg_dump to dump any object in the next
version - i suspect these two ideas will need reconciliation.Chris
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
Christopher Kings-Lynne wrote:
OK, everything for pg_dump TODO I can think of:
[snip]
* Export to other database (eg. Oracle, MySQL and DB2) formats
This strikes me as a can of worms, or to mix metaphors a bit, a rathole
from which we might never emerge.
I did have a thought the other day - now that we have COPY in/out
talking CSV format, it might be nice to have an option on pg_dump to use
CSV format rather than our own native text format.
That should make exporting to other DBs a lot easier. Of course, that
could be cutting our own throat too ...
cheers
andrew
That should make exporting to other DBs a lot easier. Of course, that
could be cutting our own throat too ...
It won't make any difference to anything. You can already dump in
INSERT format.
Being able to export to other dbs will get us _more_ users, not less.
Chris
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
That should make exporting to other DBs a lot easier. Of course, that
could be cutting our own throat too ...
It won't make any difference to anything. You can already dump in
INSERT format.
And anyway, the DDL peculiarities would be the hard part for someone to
fix, not the data formatting.
regards, tom lane
Tom Lane wrote:
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
That should make exporting to other DBs a lot easier. Of course, that
could be cutting our own throat too ...It won't make any difference to anything. You can already dump in
INSERT format.And anyway, the DDL peculiarities would be the hard part for someone to
fix, not the data formatting.
Yes, both of these are true.
cheers
andrew
On Friday 13 August 2004 00:13, Christopher Kings-Lynne wrote:
That should make exporting to other DBs a lot easier. Of course, that
could be cutting our own throat too ...It won't make any difference to anything. You can already dump in
INSERT format.Being able to export to other dbs will get us _more_ users, not less.
Without some type of corresponding import utility that seems logically false.
--
Robert Treat
Build A Better Lamp :: Linux Apache {middleware} PostgreSQL
Being able to export to other dbs will get us _more_ users, not less.
Without some type of corresponding import utility that seems logically false.
Nope. Consider it like this. How many companies are going to move to
PostgreSQL from Oracle if they cannot dump their data back to Oracle as
a failsafe? Very few. How many people will use PostgreSQL if they know
they cannot dump it over to MySQL or anything easily if they want to.
Trying to "tie in" users is pre-opensource / big commercial company
thinking.
What if they have a mixed environment, and they want to be able to give
data and dumps from postgres to their MySQL people?
Consider that no companies switched to MS Excel when it was first
invented UNTIL it could export BACK to Lotus. Otherwise, how could they
give their Excel files to other users in the office who hadn't upgraded yet?
Chris
OK, I have added a new pg_dump TODO section with adjustments based on
feedback from original list:
* pg_dump
o Allow pg_dumpall to use non-text output formats
o Have pg_dump use multi-statement transactions for INSERT dumps
o -Allow pg_dump to dump CREATE CONVERSION (Christopher)
o -Make pg_restore continue after errors, so it acts more like pg_dump
scripts
o Allow pg_dump to use multiple -t and -n switches
This should be done by allowing a '-t schema.table' syntax.
o Add dumping of comments on composite type columns
o Add dumping of comments on index columns
o Replace crude DELETE FROM method of pg_dumpall for cleaning of
users and groups with separate DROP commands
o Add dumping and restoring of LOB comments
o Stop dumping CASCADE on DROP TYPE commands in clean mode
o Add full object name to the tag field. eg. for operators we need
'=(integer, integer)', instead of just '='.
o Add pg_dumpall custom format dumps. This is probably best done by
combining pg_dump and pg_dumpall into a single binary
o Add CSV output format
---------------------------------------------------------------------------
Andrew Dunstan wrote:
Christopher Kings-Lynne wrote:
OK, everything for pg_dump TODO I can think of:
[snip]
* Export to other database (eg. Oracle, MySQL and DB2) formatsThis strikes me as a can of worms, or to mix metaphors a bit, a rathole
from which we might never emerge.I did have a thought the other day - now that we have COPY in/out
talking CSV format, it might be nice to have an option on pg_dump to use
CSV format rather than our own native text format.That should make exporting to other DBs a lot easier. Of course, that
could be cutting our own throat too ...cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073