Thread: Use a separate pg_depend.deptype for extension membership?
The extensions patch currently records that an object is part of an
extension by making a pg_depend entry with deptype 'i' (INTERNAL).
While that has the behavior we want, I wonder whether it wouldn't
be smarter in the long run to invent a new deptype for this purpose.
We do not want people confusing module membership with actual internal
dependencies, particularly not if kluges like pg_extension_flag_dump
are going to be around. (I'm currently feeling that that function
isn't going to make it into the committed patch, but sooner or later
there are likely to be similar operations.)
The main objection I can see to a new deptype is that it might confuse
client-side code that examines pg_depend. But adding all these internal
dependencies that don't mean quite what other internal dependencies do
would likely confuse such code in more subtle ways anyhow.
If we go with a new deptype, I was thinking of using 'm' (macro
DEPENDENCY_MEMBER) but am not set on that. Have we been using any
particular term to refer to the objects that belong to an extension?
regards, tom lane
On 02/04/2011 02:08 PM, Tom Lane wrote: > The extensions patch currently records that an object is part of an > extension by making a pg_depend entry with deptype 'i' (INTERNAL). > While that has the behavior we want, I wonder whether it wouldn't > be smarter in the long run to invent a new deptype for this purpose. > We do not want people confusing module membership with actual internal > dependencies, particularly not if kluges like pg_extension_flag_dump > are going to be around. (I'm currently feeling that that function > isn't going to make it into the committed patch, but sooner or later > there are likely to be similar operations.) > > The main objection I can see to a new deptype is that it might confuse > client-side code that examines pg_depend. But adding all these internal > dependencies that don't mean quite what other internal dependencies do > would likely confuse such code in more subtle ways anyhow. +1. I don't think we've ever promised not to invent new deptypes, nor should we. cheers andrew
On Fri, Feb 4, 2011 at 2:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > The extensions patch currently records that an object is part of an > extension by making a pg_depend entry with deptype 'i' (INTERNAL). > While that has the behavior we want, I wonder whether it wouldn't > be smarter in the long run to invent a new deptype for this purpose. +1. > If we go with a new deptype, I was thinking of using 'm' (macro > DEPENDENCY_MEMBER) but am not set on that. Have we been using any > particular term to refer to the objects that belong to an extension? DEPENDENCY_EXTENSION? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Tom Lane <tgl@sss.pgh.pa.us> writes:
> The extensions patch currently records that an object is part of an
> extension by making a pg_depend entry with deptype 'i' (INTERNAL).
> While that has the behavior we want, I wonder whether it wouldn't
> be smarter in the long run to invent a new deptype for this purpose.
I gave that some thoughs but as the expected behaviour already exists, I
figured it would be better for my patch to bend its head and see that
the extension's install script somehow creates INTERNAL objects.
Meaning, +1.
> We do not want people confusing module membership with actual internal
> dependencies, particularly not if kluges like pg_extension_flag_dump
> are going to be around. (I'm currently feeling that that function
> isn't going to make it into the committed patch, but sooner or later
> there are likely to be similar operations.)
This function is there so that PostGIS is able to flag some of the
objects it installs as "user data" that needs to be part of the backups.
I'll take any better design, that's only what I was able to come up
with.
> If we go with a new deptype, I was thinking of using 'm' (macro
> DEPENDENCY_MEMBER) but am not set on that. Have we been using any
> particular term to refer to the objects that belong to an extension?
Do you really think the new dependency type has to be re-usable easily
in the future? DEPENDENCY_EXTENSION ('e') would look fine by me.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> If we go with a new deptype, I was thinking of using 'm' (macro
>> DEPENDENCY_MEMBER) but am not set on that. Have we been using any
>> particular term to refer to the objects that belong to an extension?
> Do you really think the new dependency type has to be re-usable easily
> in the future? DEPENDENCY_EXTENSION ('e') would look fine by me.
Hmm ... Haas suggested that too, but to me it seems confusing: which way
does such a dependency point? But if others don't find it so, I'm
willing to go with the majority.
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes:
> Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
>> Do you really think the new dependency type has to be re-usable easily
>> in the future? DEPENDENCY_EXTENSION ('e') would look fine by me.
>
> Hmm ... Haas suggested that too, but to me it seems confusing: which way
> does such a dependency point? But if others don't find it so, I'm
> willing to go with the majority.
Well the behavior we want is the same as the DEPENDENCY_INTERNAL one, in
about all cases (e.g. DROP SCHEMA CASCADE). So I think it'd be easier
to stick with doing it the same. And then the need for specializing the
dependency kind name just raises too…
My 2¢ anyway,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support