On Wed, Nov 24, 2010 at 9:52 AM, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
