Re: pg_dump with postgis extension dumps rules separately - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_dump with postgis extension dumps rules separately
Date
Msg-id 13907.1370314623@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_dump with postgis extension dumps rules separately  (Joe Conway <mail@joeconway.com>)
Responses Re: pg_dump with postgis extension dumps rules separately
List 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 by date:

Previous
From: Joe Conway
Date:
Subject: Re: pg_dump with postgis extension dumps rules separately
Next
From: Michael Paquier
Date:
Subject: Re: MVCC catalog access