From PostgreSQL wiki
Revision as of 21:23, 14 April 2008
There has been some interest PostgreSQL extension/package/module manager.
We would like some software to make it easier for users and developers to install and manage various add-on features available for PostgreSQL.
Currently the process of installing add-ons is rather manual and cumbersome.
Recently, this topic has reappeared on pgsql-hackers mailing list:
Perhaps a difference among terms extension, package and module should be clarified? Here the term module is used, due to popular demand.
- Installing stuff from contrib
- Installing stuff from PgFoundry
- Installing user's stuff
- Convincing ISPs that modules are cool and can be easily installed and used safely
- simple apt-get or CPAN like interface, install by name
- transactional installation (module either gets installed ok or not at all)
- you should be able to tell what is installed
- should manage current contrib stuff too
- support multiple versions of databases and extensions
- create and drop (and alter) extensions in user-specified databases/schemas
- auto-get and compile and install extensions from sources from internet
- module sources: contrib, pgfoundry, user
- dependencies management (install dependencies as well)
- uninstall should use dependancies, not hand-written SQL scripts
- support for/integration with pg_dump/pg_restore
Module manager is a tool, which is specific to PostgreSQL, not a specific operating system. It should handle all tasks related to module management.
Modules are installed on local system (eg Debian Linux), per specific PostgreSQL version.
Modules are installed each in it's own directory, like:
- pg_version - postgresql version number (so multiple installations are supported)
- modulename - unique module name, (ex. hstore, tablefunc, newsysviews)
- moduleversion - debian-like version numbers. For contrib, this should probably match PostgreSQL version.
module directory should contain at least:
- SQL install instructions (file install.sql)
- SQL uninstall instructions (file uninstall.sql)
- Module information (file module.xml) - contents of this should be elaborated
This would make it easier for utilities to enumerate installed modules.
Once installed, extensions can be:
- loaded (installed in particular database/schema)
- unloaded (removed from particular database/schema)
- upgraded (to a new version)
Perhaps words CREATE, DROP and ALTER should be used?
Current contrib problems
- everything in one directory; it is clumsy to match install and uninstall files and even see, what is available
- no module versions specified (or any metadata for that matter)
- many files explicitly set schema to public:
- this is the default anyway
- it requires user to edit SQL file to change this
- this should be set by module manager, if it is to support module installation in any schema
- Move everything from contrib to appropriate dirs/files in modules directory
- Add missing module.xml files
- Make symlinks from contrib
See Also: User:Ziga/xpg_package