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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 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.

It *will* be manifestly harder to use if users have to spell the
argument types just so. Consider int4 versus integer, varchar versus
character varying (and not character varying(N)), etc etc. I think
that leaving out the argument types is something we should very strongly
consider here.

>> 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.

Apparently you haven't been reading pgsql-bugs and pgsql-novice for the
last five or ten years. These are large problems in practice.

regards, tom lane