|
| 1 | +<!-- |
| 2 | +$Header: /cvsroot/pgsql/doc/src/sgml/plhandler.sgml,v 1.1 2003/10/22 22:28:10 tgl Exp $ |
| 3 | +--> |
| 4 | + |
| 5 | + <chapter id="plhandler"> |
| 6 | + <title>Writing A Procedural Language Handler</title> |
| 7 | + |
| 8 | + <indexterm zone="plhandler"> |
| 9 | + <primary>procedural language</primary> |
| 10 | + <secondary>handler for</secondary> |
| 11 | + </indexterm> |
| 12 | + |
| 13 | + <para> |
| 14 | + All calls to functions that are written in a language other than |
| 15 | + the current <quote>version 1</quote> interface for compiled |
| 16 | + languages (this includes functions in user-defined procedural languages, |
| 17 | + functions written in SQL, and functions using the version 0 compiled |
| 18 | + language interface), go through a <firstterm>call handler</firstterm> |
| 19 | + function for the specific language. It is the responsibility of |
| 20 | + the call handler to execute the function in a meaningful way, such |
| 21 | + as by interpreting the supplied source text. This chapter outlines |
| 22 | + how a new procedural language's call handler can be written. |
| 23 | + </para> |
| 24 | + |
| 25 | + <para> |
| 26 | + The call handler for a procedural language is a |
| 27 | + <quote>normal</quote> function that must be written in a compiled |
| 28 | + language such as C, using the version-1 interface, and registered |
| 29 | + with <productname>PostgreSQL</productname> as taking no arguments |
| 30 | + and returning the type <type>language_handler</type>. This |
| 31 | + special pseudotype identifies the function as a call handler and |
| 32 | + prevents it from being called directly in SQL commands. |
| 33 | + </para> |
| 34 | + |
| 35 | + <para> |
| 36 | + The call handler is called in the same way as any other function: |
| 37 | + It receives a pointer to a |
| 38 | + <structname>FunctionCallInfoData</structname> <type>struct</> containing |
| 39 | + argument values and information about the called function, and it |
| 40 | + is expected to return a <type>Datum</type> result (and possibly |
| 41 | + set the <structfield>isnull</structfield> field of the |
| 42 | + <structname>FunctionCallInfoData</structname> structure, if it wishes |
| 43 | + to return an SQL null result). The difference between a call |
| 44 | + handler and an ordinary callee function is that the |
| 45 | + <structfield>flinfo->fn_oid</structfield> field of the |
| 46 | + <structname>FunctionCallInfoData</structname> structure will contain |
| 47 | + the OID of the actual function to be called, not of the call |
| 48 | + handler itself. The call handler must use this field to determine |
| 49 | + which function to execute. Also, the passed argument list has |
| 50 | + been set up according to the declaration of the target function, |
| 51 | + not of the call handler. |
| 52 | + </para> |
| 53 | + |
| 54 | + <para> |
| 55 | + It's up to the call handler to fetch the entry of the function from the |
| 56 | + system table |
| 57 | + <classname>pg_proc</classname> and to analyze the argument |
| 58 | + and return types of the called function. The <literal>AS</> clause from the |
| 59 | + <command>CREATE FUNCTION</command> of the function will be found |
| 60 | + in the <literal>prosrc</literal> column of the |
| 61 | + <classname>pg_proc</classname> row. This may be the source |
| 62 | + text in the procedural language itself (like for PL/Tcl), a |
| 63 | + path name to a file, or anything else that tells the call handler |
| 64 | + what to do in detail. |
| 65 | + </para> |
| 66 | + |
| 67 | + <para> |
| 68 | + Often, the same function is called many times per SQL statement. |
| 69 | + A call handler can avoid repeated lookups of information about the |
| 70 | + called function by using the |
| 71 | + <structfield>flinfo->fn_extra</structfield> field. This will |
| 72 | + initially be <symbol>NULL</>, but can be set by the call handler to point at |
| 73 | + information about the called function. On subsequent calls, if |
| 74 | + <structfield>flinfo->fn_extra</structfield> is already non-<symbol>NULL</> |
| 75 | + then it can be used and the information lookup step skipped. The |
| 76 | + call handler must make sure that |
| 77 | + <structfield>flinfo->fn_extra</structfield> is made to point at |
| 78 | + memory that will live at least until the end of the current query, |
| 79 | + since an <structname>FmgrInfo</structname> data structure could be |
| 80 | + kept that long. One way to do this is to allocate the extra data |
| 81 | + in the memory context specified by |
| 82 | + <structfield>flinfo->fn_mcxt</structfield>; such data will |
| 83 | + normally have the same lifespan as the |
| 84 | + <structname>FmgrInfo</structname> itself. But the handler could |
| 85 | + also choose to use a longer-lived memory context so that it can cache |
| 86 | + function definition information across queries. |
| 87 | + </para> |
| 88 | + |
| 89 | + <para> |
| 90 | + When a procedural-language function is invoked as a trigger, no arguments |
| 91 | + are passed in the usual way, but the |
| 92 | + <structname>FunctionCallInfoData</structname>'s |
| 93 | + <structfield>context</structfield> field points at a |
| 94 | + <structname>TriggerData</structname> structure, rather than being <symbol>NULL</> |
| 95 | + as it is in a plain function call. A language handler should |
| 96 | + provide mechanisms for procedural-language functions to get at the trigger |
| 97 | + information. |
| 98 | + </para> |
| 99 | + |
| 100 | + <para> |
| 101 | + This is a template for a procedural-language handler written in C: |
| 102 | +<programlisting> |
| 103 | +#include "postgres.h" |
| 104 | +#include "executor/spi.h" |
| 105 | +#include "commands/trigger.h" |
| 106 | +#include "fmgr.h" |
| 107 | +#include "access/heapam.h" |
| 108 | +#include "utils/syscache.h" |
| 109 | +#include "catalog/pg_proc.h" |
| 110 | +#include "catalog/pg_type.h" |
| 111 | + |
| 112 | +PG_FUNCTION_INFO_V1(plsample_call_handler); |
| 113 | + |
| 114 | +Datum |
| 115 | +plsample_call_handler(PG_FUNCTION_ARGS) |
| 116 | +{ |
| 117 | + Datum retval; |
| 118 | + |
| 119 | + if (CALLED_AS_TRIGGER(fcinfo)) |
| 120 | + { |
| 121 | + /* |
| 122 | + * Called as a trigger procedure |
| 123 | + */ |
| 124 | + TriggerData *trigdata = (TriggerData *) fcinfo->context; |
| 125 | + |
| 126 | + retval = ... |
| 127 | + } |
| 128 | + else |
| 129 | + { |
| 130 | + /* |
| 131 | + * Called as a function |
| 132 | + */ |
| 133 | + |
| 134 | + retval = ... |
| 135 | + } |
| 136 | + |
| 137 | + return retval; |
| 138 | +} |
| 139 | +</programlisting> |
| 140 | + Only a few thousand lines of code have to be added instead of the |
| 141 | + dots to complete the call handler. |
| 142 | + </para> |
| 143 | + |
| 144 | + <para> |
| 145 | + After having compiled the handler function into a loadable module |
| 146 | + (see <xref linkend="dfunc">), the following commands then |
| 147 | + register the sample procedural language: |
| 148 | +<programlisting> |
| 149 | +CREATE FUNCTION plsample_call_handler() RETURNS language_handler |
| 150 | + AS '<replaceable>filename</replaceable>' |
| 151 | + LANGUAGE C; |
| 152 | +CREATE LANGUAGE plsample |
| 153 | + HANDLER plsample_call_handler; |
| 154 | +</programlisting> |
| 155 | + </para> |
| 156 | + |
| 157 | + </chapter> |
| 158 | + |
| 159 | +<!-- Keep this comment at the end of the file |
| 160 | +Local variables: |
| 161 | +mode:sgml |
| 162 | +sgml-omittag:nil |
| 163 | +sgml-shorttag:t |
| 164 | +sgml-minimize-attributes:nil |
| 165 | +sgml-always-quote-attributes:t |
| 166 | +sgml-indent-step:1 |
| 167 | +sgml-indent-data:t |
| 168 | +sgml-parent-document:nil |
| 169 | +sgml-default-dtd-file:"./reference.ced" |
| 170 | +sgml-exposed-tags:nil |
| 171 | +sgml-local-catalogs:("/usr/lib/sgml/catalog") |
| 172 | +sgml-local-ecat-files:nil |
| 173 | +End: |
| 174 | +--> |