Re: pg_dump exclusion switches and functions/types

On Sat, Oct 07, 2006 at 06:22:19PM -0700, David Fetter wrote:
> On Fri, Oct 06, 2006 at 10:28:21PM -0400, Gregory Stark wrote:
> > Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> >
> > > The existing patch's behavior is that "the rightmost switch wins",
> > > ie, if an object's name matches more than one pattern then it is
> > > included or excluded according to the rightmost switch it matches.
> > > This is, erm, poorly documented, but it seems like useful behavior
> > > so I don't have an objection myself.
> >
> > I don't know, it sounds like it's the source of the confusion you
> > identify later.
> >
> > My first thought is that the rule should be to apply all the
> > inclusion switches (implicitly including everything if there are
> > none), then apply all the exclusion switches.
>
> +1 :)
>
> Order-dependent switches are a giant foot gun.

They're also very powerful, as anyone who's ever used them in a
non-trivial rsync (or rdiff-backup) scenareo can tell you. What if you
want to exclude all of a schema except for a few objects (granted, right
now we're limited to just tables...)?

Here's a real example, from my rdiff-backup exclude files list:

+ /opt/local/var/db/dports
+ /opt/local/var/log
+ /opt/local/etc
/opt

Note that rdiffbackup applies the first option that matches a
file/directory, not the last. So this says to exclude all of /opt,
except for /opt/local/var/db/dports, etc. If this was done as 'last
operator takes priority', you'd just reverse the order of the list:

pg_dump --exclude-schema /opt --include-table opt.local_var_db_dports
--include-table opt.local_var_log --include-table opt.local_etc

If we processed all includes first, you lose this ability. For simple
cases, it might not matter, but think about wanting to back up an entire
database, except for schema opt, but you do want a few objects from
within opt. Without following some kind of ordering on includes and
excludes, that's next to impossible.
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)