PostgreSQL is an extensible database. I hope you've learned this much by now. It is extensible by virtue of the design that it has. As discussed before, PostgreSQL uses a catalog-driven design. In fact, PostgreSQL is more catalog-driven than most of the traditional relational databases. The key benefit here is that the catalogs can be changed or added to, in order to modify or extend the database functionality. PostgreSQL also supports dynamic loading, that is, a user-written code can be provided as a shared library, and PostgreSQL will load it as required.
Extensibility is critical for many businesses, which have needs that are specific to that business or industry. Sometimes, the tools provided by the traditional database systems do not fulfill those needs. People in those businesses know best how to solve their particular problems, but they are not experts in database internals. It is often not possible for them to cook up their own database kernel or modify the core or customize it according to their needs. A truly extensible database will then allow you to do the following:
PostgreSQL not only allows you to do all of the preceding things, but also does these, and more with utmost ease. In terms of extensibility, you can do the following things in a PostgreSQL database:
So far in this book, you learned to create functions and triggers in various programming languages available in PostgreSQL, as well as create user-defined types. You also learned how to use these functions in triggers and rules. As you can see, there are many more types of extensions you can do to the database, and this provides you with all the tools you need to customize and extend the database to suit your business needs. Before we discuss the previously mentioned cases briefly, let's take a look at what you can't extend in PostgreSQL.
Although PostgreSQL is an extensible platform, there are certain things that you can't do or change without explicitly doing a fork, as follows:
3.17.79.3