Re: Use a separate pg_depend.deptype for extension membership?
От | Dimitri Fontaine |
---|---|
Тема | Re: Use a separate pg_depend.deptype for extension membership? |
Дата | |
Msg-id | m2y65v1t7e.fsf@2ndQuadrant.fr обсуждение исходный текст |
Ответ на | Use a separate pg_depend.deptype for extension membership? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Use a separate pg_depend.deptype for extension membership?
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: