Re: Suggested "easy" TODO: pg_dump --from-list

On Wed, Nov 24, 2010 at 9:52 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Actually, what occurs to me to wonder is whether the facility has to be
> guaranteed unique at all.  If for instance you have a group of overloaded
> functions, is there really a big use-case for dumping just one and not
> the whole group?  Even if you think there's some use for it, is it big
> enough to justify a quantum jump in the complexity of the feature?

Well, I think that being able to dump one specific function is a
pretty important use case. But I don't see why that's necessarily
irreconcilable with your suggested syntax of --function=pattern, if we
assume that the pattern is being matched against
pg_proc.oid::regprocedure and define the matching rules such that
foo(text) will not match sfoo(text). Nothing anyone has proposed
sounds like a quantum jump in complexity over your proposal.

> BTW, what about dependencies?  One of the main complaints we've heard
> about pg_restore's filtering features is that they are not smart about
> including things like the indexes of a selected table, or the objects it
> depends on (eg, functions referred to in CHECK constraints).  I'm not
> sure that a pure name-based filter will be any more usable than
> pg_restore's filter, if there is no accounting for dependencies.

I am 100% positive that it will be a big step forward. I think the
dependency issue is vaguely interesting, but less important and
orthogonal. This will be very useful for cherry-picking an object
from one server or database and loading it into another, a need that
comes up with some frequency. Sure, it'd be handy to be able to
cherry-pick the dependencies automatically, but you don't always need
or even want that - you may know that they are already present in the
target DB.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company