If you are new to PostgreSQL, now is the time to dance for joy.
Now that you're done dancing, I'll tell you why. You have managed to avoid the "bad old days" of contrib modules. Contrib modules are the installation systems that were used to install related PostgreSQL objects prior to Version 9.1. They may be additional data types, enhanced management functions, or just really any type of module you want to add to PostgreSQL. They consist of any group of related functions, views, tables, operators, types, and indexes that were lumped into an installation file and committed to the database in one fell swoop. Unfortunately, contrib modules only provided for installation, and nothing else. In fact, they were not really an installation system at all. They were just some unrelated SQL scripts that happened to install everything that the author thought you needed.
PostgreSQL extensions provide many new services that a package management system should have. Well, at least the ones that module authors complained the most about not being present.
Some of the new features that you will be introduced to in this chapter include:
- Versioning
- Dependencies
- Updates
- Removal
Well, first you have to understand that extensions are all about togetherness. Once the objects from a contrib module were installed, PostgreSQL provided no way to show a relationship between them. This led many developers to create their own (and at times rather ingenious) methods to version, update, upgrade, and uninstall all of the necessary "stuff" to get a feature to work.
So, the first question to ask yourself when contemplating a PostgreSQL extension as a way to publish your code is "How does all of the 'stuff' in my extension relate together?"
This question will help you make extensions that are as granular as reasonable. If the objective is to enhance PostgreSQL with the ability to provide an inventory management system, it might be better to start with an extension that provides a bill of materials data type first, and subsequently build additional extensions that are dependent upon that one. The moral of the story is to dream big, but create each extension with only the smallest number of related items that make sense.
A good example of an extension that provides a feature to PostgreSQL is OpenFTS. This extension provides full text searching capabilities to PostgreSQL by creating data types, indexes, and functions that are well related to each other.
Another type of extension is PostGIS, which provides a rich set of tools to deal with geographic information systems. Although this extension provides many more bits of functionality than OpenFTS, it is still as granular as possible by virtue of the fact that everything that is provided is necessary for geographic software development.
Possibly, you are a book author, and the only relationship that the objects in your extension have is that they need to be conveniently removed when your poor victim ...ahem...the reader is through with them. Welcome to the wonders of extensions.
For a list of very useful extensions that have gained some community popularity, you might want to take a look at this page fairly often: http://www.postgresql.org/download/products/6/.
You should also take a look at the PostgreSQL extension network at http://www.pgxn.org. Please note that installing extensions generally means running a script as a superuser; and nearly anyone can upload to pgxn, meaning that individuals really need to vet anything they get from pgxn very carefully.
Note
To find out what objects can be packaged into an extension, look at the ALTER EXTENSION ADD command in the PostgreSQL documentation:
http://www.postgresql.org/docs/current/static/sql-alterextension.html