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