Re: Use a separate pg_depend.deptype for extension membership?

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Use a separate pg_depend.deptype for extension membership?
Date: 2011-02-04 19:43:33
Message-ID: m2y65v1t7e.fsf@2ndQuadrant.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-02-04 19:44:13 OCLASS_FOREIGN_TABLE support is incomplete
Previous Message Robert Haas 2011-02-04 19:39:06 Re: Spread checkpoint sync