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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Joachim Wieland <joe(at)mcknight(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Suggested "easy" TODO: pg_dump --from-list
Date: 2010-11-24 16:14:56
Message-ID: AANLkTimf2xoFcZ12fe92rw_zL-+shWqKS-=P7vsSNp9j@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Nov 24, 2010 at 10:45 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

I don't see why this is an either/or question. Can't we make them optional?

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

That seems like a cheap shot, since you already know that I haven't
been reading any of the mailing lists for that long. I have, however,
been using PostgreSQL for that long, and I've hit this problem myself.
I don't say that being able to dump an exact object and nothing more
will solve every use case, but I do say it's useful, at least to me.
I've wanted it many times.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-11-24 16:20:38 Re: profiling connection overhead
Previous Message Tom Lane 2010-11-24 16:05:14 Re: Suggested "easy" TODO: pg_dump --from-list