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

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

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