Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Oct 10, 2011 at 2:52 PM, Tom Lane <tgl@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