Use a separate pg_depend.deptype for extension membership? - Mailing list pgsql-hackers

From Tom Lane
Subject Use a separate pg_depend.deptype for extension membership?
Date
Msg-id 16685.1296846512@sss.pgh.pa.us
Whole thread Raw
Responses Re: Use a separate pg_depend.deptype for extension membership?  (Andrew Dunstan <andrew@dunslane.net>)
Re: Use a separate pg_depend.deptype for extension membership?  (Robert Haas <robertmhaas@gmail.com>)
Re: Use a separate pg_depend.deptype for extension membership?  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: Spread checkpoint sync
Next
From: Dimitri Fontaine
Date:
Subject: Re: multiset patch review