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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Suggested "easy" TODO: pg_dump --from-list
Дата
Msg-id AANLkTimf2xoFcZ12fe92rw_zL-+shWqKS-=P7vsSNp9j@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Suggested "easy" TODO: pg_dump --from-list  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Suggested "easy" TODO: pg_dump --from-list  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, Nov 24, 2010 at 10:45 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, Nov 24, 2010 at 9:52 AM, Tom Lane <tgl@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.
>
> 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
objectand 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Suggested "easy" TODO: pg_dump --from-list
Следующее
От: Robert Haas
Дата:
Сообщение: Re: profiling connection overhead