{"id":247,"date":"2016-03-14T17:11:47","date_gmt":"2016-03-14T15:11:47","guid":{"rendered":"http:\/\/www.systemcodegeeks.com\/?p=247"},"modified":"2016-03-05T20:55:18","modified_gmt":"2016-03-05T18:55:18","slug":"creating-user-defined-c-functions-postgresql","status":"publish","type":"post","link":"https:\/\/www.systemcodegeeks.com\/databases\/postgresql\/creating-user-defined-c-functions-postgresql\/","title":{"rendered":"Creating User-Defined C Functions in PostgreSQL"},"content":{"rendered":"

Many experienced database developers are familiar with user-defined functions implemented in SQL or a procedural language. PostgreSQL itself supports PL\/pgSQL<\/a>, PL\/Tcl<\/a>, PL\/Perl<\/a>, PL\/Python<\/a>, and has third-party support for PL\/sh<\/a>, PL\/Java<\/a>, PL\/Ruby<\/a>, PL\/PHP<\/a> and even PL\/R<\/a>.<\/p>\n

Recent versions of PostgreSQL also support SQL\/MED (foreign data)<\/a> with foreign data wrappers (FDW).<\/a> This allows the database user to access foreign data sources \u2013 other RDMSes such as Oracle or MySQL, noSQL databases, even services such as twitter, as though they were PostgreSQL tables. Obviously there can be performance issues but if an architect only needs to perform a simple task, e.g., sending a tweet when certain conditions are met, it may be easier to use a FDW and database query than to incorporate native twitter support.<\/p>\n

Sometimes this is not enough. We may wish to add support for a new procedural language or foreign data wrapper. We may wish to perform work involving external libraries on the database server instead of the application server for efficiency. We may wish to hide implementation details from the database user.<\/p>\n

A subset of the last item is management of cryptographic material. Most webapps manage the cryptographic material themselves but proper key management is difficult. For instance encryption keys should be rotated on a regular basis but many webapps have never changed their database keys because there is no provision for it. Their only option is to shut down the application, run an application that loads every record, decrypts it, reencrypts it, and then updates each record. Key management on the database side is still a difficult problem but the solutions are far more likely to be reusable.<\/p>\n

PostgreSQL Extensions<\/h2>\n

It is possible to create user-defined functions in a sql script:<\/p>\n

CREATE OR REPLACE FUNCTION dgst_sha1(text)\r\nRETURNS text\r\nAS 'pgopenssltypes', 'dgst_sha1'\r\nLANGUAGE C IMMUTABLE STRICT<\/pre>\n
and provide the implementation by dropping the appropriate shared library in the $libdir<\/i> directory. See C-Language Functions<\/a> for details, or my own Introduction to PL\/Java<\/a> for examples of the SQL definitions for functions, triggers, operators, and indexes.<\/p>\n
This is unmaintainable for anything other than the smallest tasks. We want to bundle everything we need into one object that we can load and unload it in a single operation. This ensures there are no oversights or inconsistencies. PostgreSQL already has a solution to this problem: PostgreSQL Extensions<\/a>.<\/p>\n
PostgreSQL Extension Network (PGXN)<\/h2>\n
Writing a PostgreSQL extension from scratch can be tricky. A better approach is to create a skeleton using the PGXN utils<\/a> package and then install it with the pgxn-client<\/a> utility from the PostgreSQL Extension Network<\/a>.<\/p>\n
Source Code<\/h2>\n
I am not including any source code since there are numerous projects listed at the PGXN site. For instance semver (semantic version data type<\/a>, git<\/a> or pgaudit<\/a>. As always all public code should be viewed critically \u2013 you don\u2019t want to learn the wrong lessons by reading bad code. (Do not take my reference to these projects as an endorsement.)<\/p>\n
Note: if you want to use a shared library your Makefile should include the libraries in a SHLIB_LINK declaration. The system will automatically pull in any dependencies when the module is loaded.<\/p>\n
See Also<\/h2>\n