Database Reference
In-Depth Information
Chapter 10. Publishing
Your
Code
as
PostgreSQL Extensions
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 addi-
tional data types, enhanced management functions, or just really any type of mod-
ule 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 sys-
tem 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 ver-
sioning, dependencies, updates, and removal.
When to create an extension
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
sometimes 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 to-
gether?"
