Module Manager

From PostgreSQL wiki

(Difference between revisions)
Jump to: navigation, search
(i really hope this is supposed to be spelled "unloaded")
Line 1: Line 1:
 
There has been some interest PostgreSQL extension/package/module manager.
 
There has been some interest PostgreSQL extension/package/module manager.
  
Recently, this topic has reappeared on pgsql-hackers mailing list.
+
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 extensions is rather manual and cumbersome.
+
Currently the process of installing add-ons is rather manual and cumbersome.
  
We would like some software to make it easier for users and developers.
+
Recently, this topic has reappeared on pgsql-hackers mailing list:
 
+
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg00132.php 2008-04 pgsql-hackers thread]
==Links==
+
 
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01281.php 2007-10 pgsql-hackers thread]
 
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01281.php 2007-10 pgsql-hackers thread]
 
* [http://archives.postgresql.org/pgsql-patches/2006-05/msg00327.php 2006-05 pgsql-hackers thread]
 
* [http://archives.postgresql.org/pgsql-patches/2006-05/msg00327.php 2006-05 pgsql-hackers thread]
* [[User:Ziga/xpg_package]] - a proposal for package manager
+
 
 +
Perhaps a difference among terms ''extension'', ''package'' and ''module'' should be clarified?
 +
Here the term ''module'' is used, due to popular demand.
 +
 
 +
==Use Cases==
 +
* Installing stuff from ''contrib''
 +
* Installing stuff from [http://pgfoundry.org/ PgFoundry]
 +
* Installing user's stuff
 +
* Convincing ISPs that modules are cool and can be easily installed and used safely
  
 
==Wishes/Requirements==
 
==Wishes/Requirements==
 
* simple apt-get or CPAN like interface, install by name
 
* simple apt-get or CPAN like interface, install by name
* transactional installation (extension either gets installed ok or not at all)
+
* transactional installation (module either gets installed ok or not at all)
 
* you should be able to tell what is installed
 
* you should be able to tell what is installed
 
* should manage current contrib stuff too
 
* should manage current contrib stuff too
Line 20: Line 28:
 
* create and drop (and alter) extensions in user-specified databases/schemas
 
* create and drop (and alter) extensions in user-specified databases/schemas
 
* auto-get and compile and install extensions from sources from internet
 
* auto-get and compile and install extensions from sources from internet
* extension sources: contrib, pgfoundry
+
* module sources: contrib, pgfoundry, user
 
* dependencies management (install dependencies as well)
 
* dependencies management (install dependencies as well)
 
* uninstall should use dependancies, not hand-written SQL scripts
 
* uninstall should use dependancies, not hand-written SQL scripts
* support/integration with pg_dump/pg_restore
+
* support for/integration with pg_dump/pg_restore
  
===Concepts===
+
==Concepts==
Perhaps a difference among terms ''extension'', ''package'' and ''module'' should be clarified.
+
Here term extension is used.
+
  
''Extension manager'' is a tool, which is specific to PostgreSQL,  
+
''Module manager'' is a tool, which is specific to PostgreSQL,  
 
not a specific operating system. It should handle all tasks
 
not a specific operating system. It should handle all tasks
related to package management.
+
related to module management.
  
Extensions are installed on local system (eg Debian Linux), per
+
Modules are installed on local system (eg Debian Linux), per
 
specific PostgreSQL version.
 
specific PostgreSQL version.
 +
 +
Modules are installed each in it's own directory, like:
 +
 +
/usr/share/posteresql/8.3/modules/tablefunc-8.3.0/
 +
 +
path structure:
 +
 +
$base/postgresql/<i>pg_version</i>/modules/<i>modulename</i>-<i>moduleversion</i>/
 +
 +
where:
 +
* 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:
 
Once installed, extensions can be:
Line 42: Line 68:
  
 
Perhaps words CREATE, DROP and ALTER should be used?
 
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
 +
 +
Recommendations:
 +
* 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]]

Revision as of 21:22, 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.

Contents

Use Cases

  • 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

Wishes/Requirements

  • 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

Concepts

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:

/usr/share/posteresql/8.3/modules/tablefunc-8.3.0/

path structure:

$base/postgresql/pg_version/modules/modulename-moduleversion/

where:

  • 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

Recommendations:

  • 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

Personal tools