Robert Haas <robertmh...@gmail.com> writes: > On Mon, Oct 10, 2011 at 2:52 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> The underlying issue here is whether objects dependent on an extension >> member should have direct dependencies on the extension too, and if not, >> how do we prevent that? The recordDependencyOnCurrentExtension calls >> don't have enough information to know what to do, I think.
I think the original patch, that didn't have the DEPENDENCY_EXTENSION tracking but relied on the INTERNAL stuff, did only record first level objects as a dependency. Given the way INTERNAL dependencies following are done, that kind of worked in a limited set of cases. > Well, I'm not an expert on this code, but from a user perspective, I > think it would be nicer if only the view ended up being a member of > the extension, and the generated types did not. Otherwise, writing an > extension upgrade script requires detailed knowledge of what other > objects are going to be generated internally. In fact, it doesn't > seem implausible that the set of internally generated objects from a > given DDL command could change between releases, which would really be > rather ugly here. The reason why the original patch got changed by Tom is, of course, that it failed to work properly in some interesting cases. Specifically, handling both your use case and extension dependencies (earthdistance depends on cube) is not so easy. How do you know you're crossing a dependency unit when recursing in pg_depends is a nice exercise if you want to be very familiar with WITH RECURSIVE catalog queries. Been there, done that :) The main test case is DROP EXTENSION earthdistance;, adding CASCADE is easier because you then don't care about stopping at the right place. Of course I'm just trying to help you figure out why the problem is not already solved, please feel free to come back with a design that make it simple enough :) Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
