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
|
Список | 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 по дате отправления: