pg_restore multiple --function options
Hi,
While looking at the pg_restore code, I noticed that while it supports
specifying multiple --table options to restore several tables, it does
not support multiple --function options. Or --index, --schema, or --trigger.
The support for multiple --table options was added in 9.3, in January.
See
/messages/by-id/CAK3UJRG+yV1mK5twLfKVMCwXH4f6PnJou6Rn=ecabyfQH1vVHg@mail.gmail.com.
Was there a particular reason for only doing it for --table, or was it
just an oversight or lack of interest? No doubt that --table is the most
interesting one, but IMHO the other options should behave the same, for
the sake of consistency.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Aug 26, 2013 at 10:29:06PM +0300, Heikki Linnakangas wrote:
Hi,
While looking at the pg_restore code, I noticed that while it
supports specifying multiple --table options to restore several
tables, it does not support multiple --function options. Or --index,
--schema, or --trigger.The support for multiple --table options was added in 9.3, in
January. See /messages/by-id/CAK3UJRG+yV1mK5twLfKVMCwXH4f6PnJou6Rn=ecabyfQH1vVHg@mail.gmail.com.
Was there a particular reason for only doing it for --table, or was
it just an oversight or lack of interest? No doubt that --table is
the most interesting one, but IMHO the other options should behave
the same, for the sake of consistency.
+1 for making them consistent. There will also be an improvement in
usability.
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Aug 27, 2013 at 5:17 AM, David Fetter <david@fetter.org> wrote:
On Mon, Aug 26, 2013 at 10:29:06PM +0300, Heikki Linnakangas wrote:
Hi,
While looking at the pg_restore code, I noticed that while it
supports specifying multiple --table options to restore several
tables, it does not support multiple --function options. Or --index,
--schema, or --trigger.The support for multiple --table options was added in 9.3, in
January. See /messages/by-id/CAK3UJRG+yV1mK5twLfKVMCwXH4f6PnJou6Rn=ecabyfQH1vVHg@mail.gmail.com.
Was there a particular reason for only doing it for --table, or was
it just an oversight or lack of interest? No doubt that --table is
the most interesting one, but IMHO the other options should behave
the same, for the sake of consistency.+1 for making them consistent. There will also be an improvement in
usability.
+1. It would be good to have consistency there for all the objects.
--
Michael--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 27.08.2013 03:26, Michael Paquier wrote:
On Tue, Aug 27, 2013 at 5:17 AM, David Fetter<david@fetter.org> wrote:
On Mon, Aug 26, 2013 at 10:29:06PM +0300, Heikki Linnakangas wrote:
While looking at the pg_restore code, I noticed that while it
supports specifying multiple --table options to restore several
tables, it does not support multiple --function options. Or --index,
--schema, or --trigger.The support for multiple --table options was added in 9.3, in
January. See /messages/by-id/CAK3UJRG+yV1mK5twLfKVMCwXH4f6PnJou6Rn=ecabyfQH1vVHg@mail.gmail.com.
Was there a particular reason for only doing it for --table, or was
it just an oversight or lack of interest? No doubt that --table is
the most interesting one, but IMHO the other options should behave
the same, for the sake of consistency.+1 for making them consistent. There will also be an improvement in
usability.+1. It would be good to have consistency there for all the objects.
Would anyone object to backpatching that change to 9.3 ? The risk seems
very small, and it would be good to do the other options in the same
release as --table. It was an oversight to only do it for --table in 9.3.
Assuming no objections, I'll apply the attached patch to 9.3 and master
later tonight.
- Heikki
Attachments:
multiple-pg_restore-options-1.patchtext/x-diff; name=multiple-pg_restore-options-1.patchDownload
commit b6c6267cac5b87c0893f43bfb81fbd97480d5f07
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Date: Tue Aug 27 20:08:17 2013 +0300
Accept multiple -I, -P, -T and -n options in pg_restore.
We already did this for -t (--table), but missed the other similar
options. For consistency, allow all of them to be specified multiple
times.
diff --git a/doc/src/sgml/ref/pg_restore.sgml b/doc/src/sgml/ref/pg_restore.sgml
index 7c48fcd..717da42 100644
--- a/doc/src/sgml/ref/pg_restore.sgml
+++ b/doc/src/sgml/ref/pg_restore.sgml
@@ -230,7 +230,8 @@
<term><option>--index=<replaceable class="parameter">index</replaceable></option></term>
<listitem>
<para>
- Restore definition of named index only.
+ Restore definition of named index only. Multiple indexes
+ may be specified with multiple <option>-I</> switches.
</para>
</listitem>
</varlistentry>
@@ -314,7 +315,8 @@
<term><option>--schema=<replaceable class="parameter">schema</replaceable></option></term>
<listitem>
<para>
- Restore only objects that are in the named schema. This can be
+ Restore only objects that are in the named schema. Multiple schemas
+ may be specified with multiple <option>-n</> switches. This can be
combined with the <option>-t</option> option to restore just a
specific table.
</para>
@@ -348,7 +350,8 @@
<para>
Restore the named function only. Be careful to spell the function
name and arguments exactly as they appear in the dump file's table
- of contents.
+ of contents. Multiple functions may be specified with multiple
+ <option>-P</> switches.
</para>
</listitem>
</varlistentry>
@@ -413,7 +416,8 @@
<term><option>--trigger=<replaceable class="parameter">trigger</replaceable></option></term>
<listitem>
<para>
- Restore named trigger only.
+ Restore named trigger only. Multiple triggers may be specified with
+ multiple <option>-T</> switches.
</para>
</listitem>
</varlistentry>
diff --git a/src/bin/pg_dump/pg_backup.h b/src/bin/pg_dump/pg_backup.h
index b456f95..6927968 100644
--- a/src/bin/pg_dump/pg_backup.h
+++ b/src/bin/pg_dump/pg_backup.h
@@ -129,10 +129,10 @@ typedef struct _restoreOptions
int selFunction;
int selTrigger;
int selTable;
- char *indexNames;
- char *functionNames;
- char *schemaNames;
- char *triggerNames;
+ SimpleStringList indexNames;
+ SimpleStringList functionNames;
+ SimpleStringList schemaNames;
+ SimpleStringList triggerNames;
SimpleStringList tableNames;
int useDB;
diff --git a/src/bin/pg_dump/pg_backup_archiver.c b/src/bin/pg_dump/pg_backup_archiver.c
index 5204ceb..50619a2 100644
--- a/src/bin/pg_dump/pg_backup_archiver.c
+++ b/src/bin/pg_dump/pg_backup_archiver.c
@@ -2456,12 +2456,12 @@ _tocEntryRequired(TocEntry *te, teSection curSection, RestoreOptions *ropt)
}
/* Check options for selective dump/restore */
- if (ropt->schemaNames)
+ if (ropt->schemaNames.head != NULL)
{
/* If no namespace is specified, it means all. */
if (!te->namespace)
return 0;
- if (strcmp(ropt->schemaNames, te->namespace) != 0)
+ if (!(simple_string_list_member(&ropt->schemaNames, te->namespace)))
return 0;
}
@@ -2479,21 +2479,21 @@ _tocEntryRequired(TocEntry *te, teSection curSection, RestoreOptions *ropt)
{
if (!ropt->selIndex)
return 0;
- if (ropt->indexNames && strcmp(ropt->indexNames, te->tag) != 0)
+ if (ropt->indexNames.head != NULL && (!(simple_string_list_member(&ropt->indexNames, te->tag))))
return 0;
}
else if (strcmp(te->desc, "FUNCTION") == 0)
{
if (!ropt->selFunction)
return 0;
- if (ropt->functionNames && strcmp(ropt->functionNames, te->tag) != 0)
+ if (ropt->functionNames.head != NULL && (!(simple_string_list_member(&ropt->functionNames, te->tag))))
return 0;
}
else if (strcmp(te->desc, "TRIGGER") == 0)
{
if (!ropt->selTrigger)
return 0;
- if (ropt->triggerNames && strcmp(ropt->triggerNames, te->tag) != 0)
+ if (ropt->triggerNames.head != NULL && (!(simple_string_list_member(&ropt->triggerNames, te->tag))))
return 0;
}
else
diff --git a/src/bin/pg_dump/pg_restore.c b/src/bin/pg_dump/pg_restore.c
index 985c826..2648003 100644
--- a/src/bin/pg_dump/pg_restore.c
+++ b/src/bin/pg_dump/pg_restore.c
@@ -196,7 +196,7 @@ main(int argc, char **argv)
break;
case 'n': /* Dump data for this schema only */
- opts->schemaNames = pg_strdup(optarg);
+ simple_string_list_append(&opts->schemaNames, optarg);
break;
case 'O':
@@ -213,17 +213,17 @@ main(int argc, char **argv)
case 'P': /* Function */
opts->selTypes = 1;
opts->selFunction = 1;
- opts->functionNames = pg_strdup(optarg);
+ simple_string_list_append(&opts->functionNames, optarg);
break;
case 'I': /* Index */
opts->selTypes = 1;
opts->selIndex = 1;
- opts->indexNames = pg_strdup(optarg);
+ simple_string_list_append(&opts->indexNames, optarg);
break;
case 'T': /* Trigger */
opts->selTypes = 1;
opts->selTrigger = 1;
- opts->triggerNames = pg_strdup(optarg);
+ simple_string_list_append(&opts->triggerNames, optarg);
break;
case 's': /* dump schema only */
opts->schemaOnly = 1;
On Tue, Aug 27, 2013 at 08:14:32PM +0300, Heikki Linnakangas wrote:
On 27.08.2013 03:26, Michael Paquier wrote:
On Tue, Aug 27, 2013 at 5:17 AM, David Fetter<david@fetter.org> wrote:
On Mon, Aug 26, 2013 at 10:29:06PM +0300, Heikki Linnakangas wrote:
While looking at the pg_restore code, I noticed that while it
supports specifying multiple --table options to restore several
tables, it does not support multiple --function options. Or --index,
--schema, or --trigger.The support for multiple --table options was added in 9.3, in
January. See /messages/by-id/CAK3UJRG+yV1mK5twLfKVMCwXH4f6PnJou6Rn=ecabyfQH1vVHg@mail.gmail.com.
Was there a particular reason for only doing it for --table, or was
it just an oversight or lack of interest? No doubt that --table is
the most interesting one, but IMHO the other options should behave
the same, for the sake of consistency.+1 for making them consistent. There will also be an improvement in
usability.+1. It would be good to have consistency there for all the objects.
Would anyone object to backpatching that change to 9.3 ?
I'm sure someone will, but I'm not that someone. It's not as though
the added syntax could have produced anything but a runtime error if
someone had it deployed, and the improvements both in usefulness and
consistency are compelling.
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Heikki Linnakangas <hlinnakangas@vmware.com> writes:
On 27.08.2013 03:26, Michael Paquier wrote:
On Tue, Aug 27, 2013 at 5:17 AM, David Fetter<david@fetter.org> wrote:
On Mon, Aug 26, 2013 at 10:29:06PM +0300, Heikki Linnakangas wrote:
While looking at the pg_restore code, I noticed that while it
supports specifying multiple --table options to restore several
tables, it does not support multiple --function options. Or --index,
--schema, or --trigger.The support for multiple --table options was added in 9.3, in
January. See /messages/by-id/CAK3UJRG+yV1mK5twLfKVMCwXH4f6PnJou6Rn=ecabyfQH1vVHg@mail.gmail.com.
Was there a particular reason for only doing it for --table, or was
it just an oversight or lack of interest? No doubt that --table is
the most interesting one, but IMHO the other options should behave
the same, for the sake of consistency.
+1 for making them consistent. There will also be an improvement in
usability.+1. It would be good to have consistency there for all the objects.
Would anyone object to backpatching that change to 9.3 ? The risk seems
very small, and it would be good to do the other options in the same
release as --table. It was an oversight to only do it for --table in 9.3.
Assuming no objections, I'll apply the attached patch to 9.3 and master
later tonight.
I object, strongly. This is a feature addition, and has no business going
in post-rc1, especially with no time for review.
As far as the function case goes, I'm not really thrilled about layering
more functionality on that until we've come to some understanding about
how to select from a group of overloaded functions. It may be that this
is orthogonal to that issue ... or maybe not. I don't have any objection
to fixing the non-function cases, as long as it's only in HEAD.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 27.08.2013 21:56, Tom Lane wrote:
Heikki Linnakangas<hlinnakangas@vmware.com> writes:
Would anyone object to backpatching that change to 9.3 ? The risk seems
very small, and it would be good to do the other options in the same
release as --table. It was an oversight to only do it for --table in 9.3.Assuming no objections, I'll apply the attached patch to 9.3 and master
later tonight.I object, strongly. This is a feature addition, and has no business going
in post-rc1, especially with no time for review.
Ok.
As far as the function case goes, I'm not really thrilled about layering
more functionality on that until we've come to some understanding about
how to select from a group of overloaded functions. It may be that this
is orthogonal to that issue ... or maybe not. I don't have any objection
to fixing the non-function cases, as long as it's only in HEAD.
Huh, what's that issue?
As the code stands, you have to pass the argument types to the
--function flag, ie. --function="myfunc(integer)". It's annoyingly picky
about the spelling, as the it has to match exactly what pg_dump prints,
but it does handle selecting one function from a group of overloaded
ones. And that really is orthogonal to whether or not you can give
multiple --function arguments.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 08/27/2013 10:14 AM, Heikki Linnakangas wrote:
Would anyone object to backpatching that change to 9.3 ? The risk seems
very small, and it would be good to do the other options in the same
release as --table. It was an oversight to only do it for --table in 9.3.Assuming no objections, I'll apply the attached patch to 9.3 and master
later tonight.
That will pretty much force us to do an RC2, and therefore push back
final release date.
Just for consideration.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Import Notes
Reply to msg id not found: WMf04634d5cc6785dc516b75e1d18f40f130a4418fd4c2ab99700f35e5e13eaf5f29e2228f743a7fb8ebadc957691f007c@asav-1.01.com
Heikki Linnakangas <hlinnakangas@vmware.com> writes:
As the code stands, you have to pass the argument types to the
--function flag, ie. --function="myfunc(integer)". It's annoyingly picky
about the spelling, as the it has to match exactly what pg_dump prints,
but it does handle selecting one function from a group of overloaded
ones.
Oh --- OK, I was misremembering. I recalled that people weren't happy
with the handling of --function, but had the details wrong.
[pokes around]
I think really the issues are (1) it only works in pg_restore, not
pg_dump, and (2) there's no wildcard matching (the pickiness about
argument type name spelling being perhaps a subset of that).
It's probably true that accepting multiple patterns doesn't preclude
solving either of those, and indeed might help users work around (2).
So nevermind that objection. But I still say this is all too late
for 9.3.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Aug 27, 2013 at 10:35:40PM +0300, Heikki Linnakangas wrote:
On 27.08.2013 21:56, Tom Lane wrote:
Heikki Linnakangas<hlinnakangas@vmware.com> writes:
Would anyone object to backpatching that change to 9.3 ? The risk seems
very small, and it would be good to do the other options in the same
release as --table. It was an oversight to only do it for --table in 9.3.Assuming no objections, I'll apply the attached patch to 9.3 and master
later tonight.I object, strongly. This is a feature addition, and has no business going
in post-rc1, especially with no time for review.Ok.
As far as the function case goes, I'm not really thrilled about layering
more functionality on that until we've come to some understanding about
how to select from a group of overloaded functions. It may be that this
is orthogonal to that issue ... or maybe not. I don't have any objection
to fixing the non-function cases, as long as it's only in HEAD.Huh, what's that issue?
As the code stands, you have to pass the argument types to the
--function flag, ie. --function="myfunc(integer)". It's annoyingly
picky about the spelling, as the it has to match exactly what
pg_dump prints, but it does handle selecting one function from a
group of overloaded ones. And that really is orthogonal to whether
or not you can give multiple --function arguments.
Come to think of it, some kind of recognition that functions can come
in several flavors would be awesome, e.g.
--function=myfunc\*
which would capture all variants of myfunc.
Let the bikeshedding begin!
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Aug 27, 2013 at 1:14 PM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
Assuming no objections, I'll apply the attached patch to 9.3 and master
later tonight.
Just a little stylistic nitpick: could we pluralize the --help outputs
for the modified options so that they make clear that multiple
specifications are supported. E.g. "restore named index(es)" instead
of just "restore named index". The last round of such changes tried to
make such --help tweaks, it would be nice to keep 'em consistent.
Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Sep 5, 2013 at 09:15:09PM -0400, Josh Kupershmidt wrote:
On Tue, Aug 27, 2013 at 1:14 PM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:Assuming no objections, I'll apply the attached patch to 9.3 and master
later tonight.Just a little stylistic nitpick: could we pluralize the --help outputs
for the modified options so that they make clear that multiple
specifications are supported. E.g. "restore named index(es)" instead
of just "restore named index". The last round of such changes tried to
make such --help tweaks, it would be nice to keep 'em consistent.
Agreed. Attached patch applied.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
Attachments:
restore.difftext/x-diff; charset=us-asciiDownload
diff --git a/src/bin/pg_dump/pg_restore.c b/src/bin/pg_dump/pg_restore.c
index 2648003..bb65253 100644
--- a/src/bin/pg_dump/pg_restore.c
+++ b/src/bin/pg_dump/pg_restore.c
@@ -442,17 +442,17 @@ usage(const char *progname)
printf(_(" -c, --clean clean (drop) database objects before recreating\n"));
printf(_(" -C, --create create the target database\n"));
printf(_(" -e, --exit-on-error exit on error, default is to continue\n"));
- printf(_(" -I, --index=NAME restore named index\n"));
+ printf(_(" -I, --index=NAME restore named indexes\n"));
printf(_(" -j, --jobs=NUM use this many parallel jobs to restore\n"));
printf(_(" -L, --use-list=FILENAME use table of contents from this file for\n"
" selecting/ordering output\n"));
- printf(_(" -n, --schema=NAME restore only objects in this schema\n"));
+ printf(_(" -n, --schema=NAME restore only objects in these schemas\n"));
printf(_(" -O, --no-owner skip restoration of object ownership\n"));
- printf(_(" -P, --function=NAME(args) restore named function\n"));
+ printf(_(" -P, --function=NAME(args) restore named functions\n"));
printf(_(" -s, --schema-only restore only the schema, no data\n"));
printf(_(" -S, --superuser=NAME superuser user name to use for disabling triggers\n"));
- printf(_(" -t, --table=NAME restore named table(s)\n"));
- printf(_(" -T, --trigger=NAME restore named trigger\n"));
+ printf(_(" -t, --table=NAME restore named tables\n"));
+ printf(_(" -T, --trigger=NAME restore named triggers\n"));
printf(_(" -x, --no-privileges skip restoration of access privileges (grant/revoke)\n"));
printf(_(" -1, --single-transaction restore as a single transaction\n"));
printf(_(" --disable-triggers disable triggers during data-only restore\n"));
@@ -460,7 +460,7 @@ usage(const char *progname)
" created\n"));
printf(_(" --no-security-labels do not restore security labels\n"));
printf(_(" --no-tablespaces do not restore tablespace assignments\n"));
- printf(_(" --section=SECTION restore named section (pre-data, data, or post-data)\n"));
+ printf(_(" --section=SECTION restore named sections (pre-data, data, or post-data)\n"));
printf(_(" --use-set-session-authorization\n"
" use SET SESSION AUTHORIZATION commands instead of\n"
" ALTER OWNER commands to set ownership\n"));