Database Reference
In-Depth Information
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 man-
agement system, maybe it would be better to start with an extension that provides
a bill of material's 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 topic author, and the only relationship that the objects in your ex-
tension 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:
You should also take a look at the PostgreSQL extension network at
ht-
To find out what objects can be packaged into an extension, look at the
ALTER
EXTENSION ADD
command in the PostgreSQL documentation:
