Chapter 14. PostgreSQL as an Extensible RDBMS

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:

  • Solve domain-specific problems in a seamless way, like a native solution
  • Build complete features without modifying the core database engine
  • Extend the database without interrupting availability

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:

  1. Create your own data types
  2. Create your own functions
  3. Create your own aggregates
  4. Create your own operators
  5. Create your own index access methods (operator classes)
  6. Create your own server programming language
  7. Create foreign data wrappers (SQL/MED) and foreign tables

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.

What can't be extended?

Although PostgreSQL is an extensible platform, there are certain things that you can't do or change without explicitly doing a fork, as follows:

  1. You can't change or plug in a new storage engine. If you are coming from the MySQL world, this might annoy you a little. However, PostgreSQL's storage engine is tightly coupled with its executor and the rest of the system, which has its own benefits.
  2. You can't plug in your own planner/parser. One can argue for and against the ability to do that, but at the moment, the planner, parser, optimizer, and so on are baked into the system and there is no possibility of replacing them. There has been some talk on this topic, and if you are of the curious kind, you can read some of the discussion at http://bit.ly/1yRMkK7.
  3. We will now briefly discuss some more of the extensibility capabilities of PostgreSQL. We will not dive deep into the topics, but we will point you to the appropriate link where more information can be found. The chapter material will serve as an easy-to-understand introductory tutorial on the subject matter. It is by no means a comprehensive discussion of the topics.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.17.79.3