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

Search Discussions

  • Andrew Dunstan at Feb 4, 2011 at 7:26 pm

    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
  • Robert Haas at Feb 4, 2011 at 7:38 pm

    On Fri, Feb 4, 2011 at 2: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. +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
  • Dimitri Fontaine at Feb 4, 2011 at 7:43 pm

    Tom Lane 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
  • Tom Lane at Feb 4, 2011 at 7:48 pm

    Dimitri Fontaine 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
  • Dimitri Fontaine at Feb 4, 2011 at 7:51 pm

    Tom Lane 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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedFeb 4, '11 at 7:08p
activeFeb 4, '11 at 7:51p
posts6
users4
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase