Thread: pg_dump feature request: Exclude tables?
> No, we have: > > * Allow pg_dump to use multiple -t and -n switches > > This should be done by allowing a '-t schema.table' syntax. > > but that doesn't have the exclude option. We had a patch that > implemented an exclude but got confused over how it would interact with > the schema switch and stuff. However, with the new '-t schema.table' > syntax we might be able to get it working. Hmm, while you're at it, maybe you could make it accept wild cards or regexp or something :-) That should allow you to toss the -n parameter altogether (schema.*) if you wanted to. It would also be at least as good, IMO, to accept only one -t option, re-defined as a comma-seperated list of names... And an exlusion parameter defined the same way. Glen Parker glenebob@nwlink.com
Glen Parker wrote: >>No, we have: >> >> * Allow pg_dump to use multiple -t and -n switches >> >> This should be done by allowing a '-t schema.table' syntax. >> >>but that doesn't have the exclude option. We had a patch that >>implemented an exclude but got confused over how it would interact with >>the schema switch and stuff. However, with the new '-t schema.table' >>syntax we might be able to get it working. >> >> > >Hmm, while you're at it, maybe you could make it accept wild >cards or regexp or something :-) That should allow you to toss >the -n parameter altogether (schema.*) if you wanted to. > >It would also be at least as good, IMO, to accept only one -t >option, re-defined as a comma-seperated list of names... And an >exlusion parameter defined the same way. > > > How would this interact with the shell? It seems like a supportability issue if we have to require single quotes around such arguments. Best Wishes, Chris Travers Metatron Technology Consulting
> >Hmm, while you're at it, maybe you could make it accept wild > >cards or regexp or something :-) That should allow you to toss > >the -n parameter altogether (schema.*) if you wanted to. > > > >It would also be at least as good, IMO, to accept only one -t > >option, re-defined as a comma-seperated list of names... And an > >exlusion parameter defined the same way. > > > How would this interact with the shell? It seems like a supportability > issue if we have to require single quotes around such arguments. I think wild cards would be extremely useful, but you're right, it can't be required for common cases. Maybe "-t schema." could be shorthand for "-t schema.*". As far as the comma-seperated-list notion, I could take it or leave it. But it absolutely does not require quoting unless you add superfluous whitespace. That's just common, basic shell usage. Glen Parker glenebob@nwlink.com
On Wed, 2004-08-18 at 20:11, Glen Parker wrote: > > >Hmm, while you're at it, maybe you could make it accept wild > > >cards or regexp or something :-) That should allow you to toss > > >the -n parameter altogether (schema.*) if you wanted to. > > > > > >It would also be at least as good, IMO, to accept only one -t > > >option, re-defined as a comma-seperated list of names... And an > > >exlusion parameter defined the same way. > > > > > How would this interact with the shell? It seems like a supportability > > issue if we have to require single quotes around such arguments. > > I think wild cards would be extremely useful, but you're right, it can't be > required for common cases. Maybe "-t schema." could be shorthand for "-t > schema.*". Anyone who uses shell commands must already be familiar with the need to quote wildcard characters which are not meant for the shell. One major utility which requires this is find; others that spring to mind are dpkg -l and mmv. Anyone who doesn't get it will very soon be educated; I don't see this issue as a reason not to use such wildcards. Oliver Elphick