index ca5e6efd7e46b5bcd470a89c94e7378b46a2d7b4..a91f8871191ec857b8496ca6206113dca0fbf7d5 100644 (file)
<para>
In a version-1 function, each actual argument is fetched using a
<function>PG_GETARG_<replaceable>xxx</replaceable>()</function>
- macro that corresponds to the argument's data type. In non-strict
+ macro that corresponds to the argument's data type. (In non-strict
functions there needs to be a previous check about argument null-ness
- using <function>PG_ARGNULL_<replaceable>xxx</replaceable>()</function>.
+ using <function>PG_ARGISNULL()</function>; see below.)
The result is returned using a
<function>PG_RETURN_<replaceable>xxx</replaceable>()</function>
macro for the return type.
@@ -2401,14 +2401,6 @@ CREATE FUNCTION concat_text(text, text) RETURNS text
explicitly, using <function>PG_ARGISNULL()</function>.
</para>
- <para>
- At first glance, the version-1 coding conventions might appear to be just
- pointless obscurantism, over using plain <literal>C</literal> calling
- conventions. They do however allow to deal with <literal>NULL</literal>able
- arguments/return values, and <quote>toasted</quote> (compressed or
- out-of-line) values.
- </para>
-
<para>
The macro <function>PG_ARGISNULL(<replaceable>n</replaceable>)</function>
allows a function to test whether each input is null. (Of course, doing
@@ -2423,6 +2415,14 @@ CREATE FUNCTION concat_text(text, text) RETURNS text
this works in both strict and nonstrict functions.
</para>
+ <para>
+ At first glance, the version-1 coding conventions might appear
+ to be just pointless obscurantism, compared to using
+ plain <literal>C</literal> calling conventions. They do however allow
+ us to deal with <literal>NULL</literal>able arguments/return values,
+ and <quote>toasted</quote> (compressed or out-of-line) values.
+ </para>
+
<para>
Other options provided by the version-1 interface are two
variants of the