diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2020-03-13 12:49:10 -0400 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2020-03-13 12:49:10 -0400 |
| commit | dbf95c843a3d66cf9a692f5937a1bec4f2261035 (patch) | |
| tree | f88609b6c0f7654fa8082870b65d163ab89751eb /doc/src | |
| parent | 340de72780e4eb769d5cf052b03084808bac476a (diff) | |
| download | postgresql-dbf95c843a3d66cf9a692f5937a1bec4f2261035.tar.gz postgresql-dbf95c843a3d66cf9a692f5937a1bec4f2261035.zip | |
Doc: fix mistaken reference to "PG_ARGNULL_xxx()" macro.
This should of course be just "PG_ARGISNULL()".
Also reorder a couple of paras to make the discussion of PG_ARGISNULL
less disjointed.
Back-patch to v10 where the error was introduced.
Laurenz Albe and Tom Lane, per an anonymous docs comment
Discussion: https://postgr.es/m/158399487096.5708.10696365251766477013@wrigleys.postgresql.org
Diffstat (limited to 'doc/src')
| -rw-r--r-- | doc/src/sgml/xfunc.sgml | 20 |
1 files changed, 10 insertions, 10 deletions
diff --git a/doc/src/sgml/xfunc.sgml b/doc/src/sgml/xfunc.sgml index ca5e6efd7e4..a91f8871191 100644 --- a/doc/src/sgml/xfunc.sgml +++ b/doc/src/sgml/xfunc.sgml @@ -2237,9 +2237,9 @@ PG_FUNCTION_INFO_V1(funcname); <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. @@ -2402,14 +2402,6 @@ CREATE FUNCTION concat_text(text, text) RETURNS text </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 is only necessary in functions not declared <quote>strict</quote>.) @@ -2424,6 +2416,14 @@ CREATE FUNCTION concat_text(text, text) RETURNS text </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 <function>PG_GETARG_<replaceable>xxx</replaceable>()</function> |