Re: pg_dump with postgis extension dumps rules separately

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_dump with postgis extension dumps rules separately
Дата
Msg-id 13907.1370314623@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_dump with postgis extension dumps rules separately  (Joe Conway <mail@joeconway.com>)
Ответы Re: pg_dump with postgis extension dumps rules separately  (Joe Conway <mail@joeconway.com>)
Список pgsql-hackers
Joe Conway <mail@joeconway.com> writes:
> I was surprised by a couple of things looking at this code. First,
> getRules() is written differently than other table subsidiary objects'
> get functions. Secondly, I would have expected
> getExtensionMembership() to be recursive -- instead it looks to only
> go one level deep. Perhaps the longer term fix would be to identify
> extension dependencies recursively, and then the reliance on strict
> ordering here could be relaxed. But I don't think we want to make that
> change in 9.3 at this point.

I'm not sure that's appropriate: extension membership is not a recursive
concept AFAICS.  In any case, as you say, it's something for more
analysis later.

> Objections to this version?

I'd have put the getRules call where getEventTriggers is now, or at
least adjacent to getTriggers in one direction or the other.  I'm
not sure there is anything functionally wrong with what you have here;
but IMO rules and table-level triggers are pretty much the same kind
of critters so far as pg_dump is concerned, to wit, they're table
properties not free-standing objects (which is exactly the point of this
change).  So it seems to me to make sense to process them together.

BTW, don't forget that the getRules move needs to be back-patched.
        regards, tom lane



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

Предыдущее
От: Joe Conway
Дата:
Сообщение: Re: pg_dump with postgis extension dumps rules separately
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: MVCC catalog access