Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Chapter 32. Extending SQL

Table of Contents
32.1. How Extensibility Works
32.2. The PostgreSQL Type System
32.2.1. Base Types
32.2.2. Composite Types
32.2.3. Domains
32.2.4. Pseudo-Types
32.2.5. Polymorphic Types
32.3. User-Defined Functions
32.4. Query Language (SQL) Functions
32.4.1. SQL Functions on Base Types
32.4.2. SQL Functions on Composite Types
32.4.3. Functions with Output Parameters
32.4.4. SQL Functions as Table Sources
32.4.5. SQL Functions Returning Sets
32.4.6. Polymorphic SQL Functions
32.5. Function Overloading
32.6. Function Volatility Categories
32.7. Procedural Language Functions
32.8. Internal Functions
32.9. C-Language Functions
32.9.1. Dynamic Loading
32.9.2. Base Types in C-Language Functions
32.9.3. Calling Conventions Version 0 for C-Language Functions
32.9.4. Calling Conventions Version 1 for C-Language Functions
32.9.5. Writing Code
32.9.6. Compiling and Linking Dynamically-Loaded Functions
32.9.7. Extension Building Infrastructure
32.9.8. Composite-Type Arguments in C-Language Functions
32.9.9. Returning Rows (Composite Types) from C-Language Functions
32.9.10. Returning Sets from C-Language Functions
32.9.11. Polymorphic Arguments and Return Types
32.10. User-Defined Aggregates
32.11. User-Defined Types
32.12. User-Defined Operators
32.13. Operator Optimization Information
32.13.1. COMMUTATOR
32.13.2. NEGATOR
32.13.3. RESTRICT
32.13.4. JOIN
32.13.5. HASHES
32.13.6. MERGES (SORT1, SORT2, LTCMP, GTCMP)
32.14. Interfacing Extensions To Indexes
32.14.1. Index Methods and Operator Classes
32.14.2. Index Method Strategies
32.14.3. Index Method Support Routines
32.14.4. An Example
32.14.5. Cross-Data-Type Operator Classes
32.14.6. System Dependencies on Operator Classes
32.14.7. Special Features of Operator Classes

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

32.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.


 
 
  Published courtesy of The PostgreSQL Global Development Group Design by Interspire