Chapter 34. Extending SQL

Table of Contents
34.1. How Extensibility Works
34.2. The PostgreSQL Type System
34.3. User-Defined Functions
34.4. Query Language (SQL) Functions
34.4.1. SQL Functions on Base Types
34.4.2. SQL Functions on Composite Types
34.4.3. SQL Functions as Table Sources
34.4.4. SQL Functions Returning Sets
34.5. Procedural Language Functions
34.6. Internal Functions
34.7. C-Language Functions
34.7.1. Dynamic Loading
34.7.2. Base Types in C-Language Functions
34.7.3. Calling Conventions Version 0 for C-Language Functions
34.7.4. Calling Conventions Version 1 for C-Language Functions
34.7.5. Writing Code
34.7.6. Compiling and Linking Dynamically-Loaded Functions
34.7.7. Composite-Type Arguments in C-Language Functions
34.7.8. Returning Rows (Composite Types) from C-Language Functions
34.7.9. Returning Sets from C-Language Functions
34.8. Function Overloading
34.9. Procedural Language Handlers
34.10. User-Defined Types
34.11. User-defined Operators
34.12. Operator Optimization Information
34.12.1. COMMUTATOR
34.12.2. NEGATOR
34.12.3. RESTRICT
34.12.4. JOIN
34.12.5. HASHES
34.12.6. MERGES (SORT1, SORT2, LTCMP, GTCMP)
34.13. User-Defined Aggregates
34.14. Interfacing Extensions To Indexes
34.14.1. Index Methods and Operator Classes
34.14.2. Index Method Strategies
34.14.3. Index Method Support Routines
34.14.4. An Example
34.14.5. Special Features of Operator Classes

In the sections that follow, we will discuss how you can extend the PostgreSQL SQL query language by adding:

34.1. How Extensibility Works

PostgreSQL is extensible because its operation is catalog-driven. If you are familiar with standard relational database systems, you know that they store information about databases, tables, columns, etc., in what are commonly known as system catalogs. (Some systems call this the data dictionary). The catalogs appear to the user as tables like any other, but the DBMS stores its internal bookkeeping in them. One key difference between PostgreSQL and standard relational database systems is that PostgreSQL stores much more information in its catalogs: not only information about tables and columns, but also information about data types, functions, access methods, and so on. These tables can be modified by the user, and since PostgreSQL bases its operation on these tables, this means that PostgreSQL can be extended by users. By comparison, conventional database systems can only be extended by changing hardcoded procedures in the source code or by loading modules specially written by the DBMS vendor.

The PostgreSQL server can moreover incorporate user-written code into itself through dynamic loading. That is, the user can specify an object code file (e.g., a shared library) that implements a new type or function, and PostgreSQL will load it as required. Code written in SQL is even more trivial to add to the server. This ability to modify its operation "on the fly" makes PostgreSQL uniquely suited for rapid prototyping of new applications and storage structures.