doc: Update uses of the word "procedure"

Historically, the term procedure was used as a synonym for function in
Postgres/PostgreSQL.  Now we have procedures as separate objects from
functions, so we need to clean up the documentation to not mix those
terms.

In particular, mentions of "trigger procedures" are changed to "trigger
functions", and access method "support procedures" are changed to
"support functions".  (The latter already used FUNCTION in the SQL
syntax anyway.)  Also, the terminology in the SPI chapter has been
cleaned up.

A few tests, examples, and code comments are also adjusted to be
consistent with documentation changes, but not everything.

Reported-by: Peter Geoghegan <pg@bowt.ie>
Reviewed-by: Jonathan S. Katz <jonathan.katz@excoventures.com>

Author: petere

doc/src/sgml/brin.sgml

@@ -537,7 +537,7 @@ typedef struct BrinOpcInfo
 } BrinOpcInfo;
 </programlisting>
       <structname>BrinOpcInfo</structname>.<structfield>oi_opaque</structfield> can be used by the
-      operator class routines to pass information between support procedures
+      operator class routines to pass information between support functions
       during an index scan.
      </para>
     </listitem>
@@ -587,27 +587,27 @@ typedef struct BrinOpcInfo
   defined by the user for other data types using equivalent definitions,
   without having to write any source code; appropriate catalog entries being
   declared is enough.  Note that assumptions about the semantics of operator
-  strategies are embedded in the support procedures' source code.
+  strategies are embedded in the support functions' source code.
  </para>
 
  <para>
   Operator classes that implement completely different semantics are also
-  possible, provided implementations of the four main support procedures
+  possible, provided implementations of the four main support functions
   described above are written.  Note that backwards compatibility across major
-  releases is not guaranteed: for example, additional support procedures might
+  releases is not guaranteed: for example, additional support functions might
   be required in later releases.
  </para>
 
  <para>
   To write an operator class for a data type that implements a totally
-  ordered set, it is possible to use the minmax support procedures
+  ordered set, it is possible to use the minmax support functions
   alongside the corresponding operators, as shown in
   <xref linkend="brin-extensibility-minmax-table"/>.
-  All operator class members (procedures and operators) are mandatory.
+  All operator class members (functions and operators) are mandatory.
  </para>
 
  <table id="brin-extensibility-minmax-table">
-  <title>Procedure and Support Numbers for Minmax Operator Classes</title>
+  <title>Function and Support Numbers for Minmax Operator Classes</title>
   <tgroup cols="2">
    <thead>
     <row>
@@ -617,19 +617,19 @@ typedef struct BrinOpcInfo
    </thead>
    <tbody>
     <row>
-     <entry>Support Procedure 1</entry>
+     <entry>Support Function 1</entry>
      <entry>internal function <function>brin_minmax_opcinfo()</function></entry>
     </row>
     <row>
-     <entry>Support Procedure 2</entry>
+     <entry>Support Function 2</entry>
      <entry>internal function <function>brin_minmax_add_value()</function></entry>
     </row>
     <row>
-     <entry>Support Procedure 3</entry>
+     <entry>Support Function 3</entry>
      <entry>internal function <function>brin_minmax_consistent()</function></entry>
     </row>
     <row>
-     <entry>Support Procedure 4</entry>
+     <entry>Support Function 4</entry>
      <entry>internal function <function>brin_minmax_union()</function></entry>
     </row>
     <row>
@@ -659,7 +659,7 @@ typedef struct BrinOpcInfo
  <para>
   To write an operator class for a complex data type which has values
   included within another type, it's possible to use the inclusion support
-  procedures alongside the corresponding operators, as shown
+  functions alongside the corresponding operators, as shown
   in <xref linkend="brin-extensibility-inclusion-table"/>.  It requires
   only a single additional function, which can be written in any language.
   More functions can be defined for additional functionality.  All operators
@@ -668,7 +668,7 @@ typedef struct BrinOpcInfo
  </para>
 
  <table id="brin-extensibility-inclusion-table">
-  <title>Procedure and Support Numbers for Inclusion Operator Classes</title>
+  <title>Function and Support Numbers for Inclusion Operator Classes</title>
   <tgroup cols="3">
    <thead>
     <row>
@@ -679,42 +679,42 @@ typedef struct BrinOpcInfo
    </thead>
    <tbody>
     <row>
-     <entry>Support Procedure 1</entry>
+     <entry>Support Function 1</entry>
      <entry>internal function <function>brin_inclusion_opcinfo()</function></entry>
      <entry></entry>
     </row>
     <row>
-     <entry>Support Procedure 2</entry>
+     <entry>Support Function 2</entry>
      <entry>internal function <function>brin_inclusion_add_value()</function></entry>
      <entry></entry>
     </row>
     <row>
-     <entry>Support Procedure 3</entry>
+     <entry>Support Function 3</entry>
      <entry>internal function <function>brin_inclusion_consistent()</function></entry>
      <entry></entry>
     </row>
     <row>
-     <entry>Support Procedure 4</entry>
+     <entry>Support Function 4</entry>
      <entry>internal function <function>brin_inclusion_union()</function></entry>
      <entry></entry>
     </row>
     <row>
-     <entry>Support Procedure 11</entry>
+     <entry>Support Function 11</entry>
      <entry>function to merge two elements</entry>
      <entry></entry>
     </row>
     <row>
-     <entry>Support Procedure 12</entry>
+     <entry>Support Function 12</entry>
      <entry>optional function to check whether two elements are mergeable</entry>
      <entry></entry>
     </row>
     <row>
-     <entry>Support Procedure 13</entry>
+     <entry>Support Function 13</entry>
      <entry>optional function to check if an element is contained within another</entry>
      <entry></entry>
     </row>
     <row>
-     <entry>Support Procedure 14</entry>
+     <entry>Support Function 14</entry>
      <entry>optional function to check whether an element is empty</entry>
      <entry></entry>
     </row>
@@ -803,7 +803,7 @@ typedef struct BrinOpcInfo
  </table>
 
  <para>
-    Support procedure numbers 1-10 are reserved for the BRIN internal
+    Support function numbers 1-10 are reserved for the BRIN internal
     functions, so the SQL level functions start with number 11.  Support
     function number 11 is the main function required to build the index.
     It should accept two arguments with the same data type as the operator class,
@@ -814,11 +814,11 @@ typedef struct BrinOpcInfo
  </para>
 
  <para>
-    Support procedure numbers 12 and 14 are provided to support
-    irregularities of built-in data types.  Procedure number 12
+    Support function numbers 12 and 14 are provided to support
+    irregularities of built-in data types.  Function number 12
     is used to support network addresses from different families which
-    are not mergeable.  Procedure number 14 is used to support
-    empty ranges.  Procedure number 13 is an optional but
+    are not mergeable.  Function number 14 is used to support
+    empty ranges.  Function number 13 is an optional but
     recommended one, which allows the new value to be checked before
     it is passed to the union function.  As the BRIN framework can shortcut
     some operations when the union is not changed, using this

doc/src/sgml/catalogs.sgml

@@ -67,7 +67,7 @@
 
      <row>
       <entry><link linkend="catalog-pg-amproc"><structname>pg_amproc</structname></link></entry>
-      <entry>access method support procedures</entry>
+      <entry>access method support functions</entry>
      </row>
 
      <row>
@@ -814,8 +814,8 @@
 
   <para>
    The catalog <structname>pg_amproc</structname> stores information about
-   support procedures associated with access method operator families.  There
-   is one row for each support procedure belonging to an operator family.
+   support functions associated with access method operator families.  There
+   is one row for each support function belonging to an operator family.
   </para>
 
   <table>
@@ -864,14 +864,14 @@
       <entry><structfield>amprocnum</structfield></entry>
       <entry><type>int2</type></entry>
       <entry></entry>
-      <entry>Support procedure number</entry>
+      <entry>Support function number</entry>
      </row>
 
      <row>
       <entry><structfield>amproc</structfield></entry>
       <entry><type>regproc</type></entry>
       <entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
-      <entry>OID of the procedure</entry>
+      <entry>OID of the function</entry>
      </row>
 
     </tbody>
@@ -882,9 +882,9 @@
    The usual interpretation of the
    <structfield>amproclefttype</structfield> and <structfield>amprocrighttype</structfield> fields
    is that they identify the left and right input types of the operator(s)
-   that a particular support procedure supports.  For some access methods
-   these match the input data type(s) of the support procedure itself, for
-   others not.  There is a notion of <quote>default</quote> support procedures for
+   that a particular support function supports.  For some access methods
+   these match the input data type(s) of the support function itself, for
+   others not.  There is a notion of <quote>default</quote> support functions for
    an index, which are those with <structfield>amproclefttype</structfield> and
    <structfield>amprocrighttype</structfield> both equal to the index operator class's
    <structfield>opcintype</structfield>.
@@ -2471,7 +2471,7 @@ SCRAM-SHA-256$<replaceable>&lt;iteration count&gt;</replaceable>:<replaceable>&l
 
   <para>
    The catalog <structname>pg_conversion</structname> describes
-   encoding conversion procedures.  See <xref linkend="sql-createconversion"/>
+   encoding conversion functions.  See <xref linkend="sql-createconversion"/>
    for more information.
   </para>
 
@@ -2537,7 +2537,7 @@ SCRAM-SHA-256$<replaceable>&lt;iteration count&gt;</replaceable>:<replaceable>&l
       <entry><structfield>conproc</structfield></entry>
       <entry><type>regproc</type></entry>
       <entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
-      <entry>Conversion procedure</entry>
+      <entry>Conversion function</entry>
      </row>
 
      <row>

doc/src/sgml/event-trigger.sgml

@@ -1053,9 +1053,9 @@ CREATE EVENT TRIGGER noddl ON ddl_command_start
 <screen>
 =# \dy
                      List of event triggers
- Name  |       Event       | Owner | Enabled | Procedure | Tags
--------+-------------------+-------+---------+-----------+------
- noddl | ddl_command_start | dim   | enabled | noddl     |
+ Name  |       Event       | Owner | Enabled | Function | Tags
+-------+-------------------+-------+---------+----------+------
+ noddl | ddl_command_start | dim   | enabled | noddl    |
 (1 row)
 
 =# CREATE TABLE foo(id serial);

doc/src/sgml/func.sgml

@@ -12360,7 +12360,7 @@ SELECT setval('foo', 42, false);    <lineannotation>Next <function>nextval</func
   <tip>
    <para>
     If your needs go beyond the capabilities of these conditional
-    expressions, you might want to consider writing a stored procedure
+    expressions, you might want to consider writing a server-side function
     in a more expressive programming language.
    </para>
   </tip>

doc/src/sgml/plhandler.sgml

@@ -119,7 +119,7 @@ plsample_call_handler(PG_FUNCTION_ARGS)
     if (CALLED_AS_TRIGGER(fcinfo))
     {
         /*
-         * Called as a trigger procedure
+         * Called as a trigger function
          */
         TriggerData    *trigdata = (TriggerData *) fcinfo->context;
 

doc/src/sgml/plperl.sgml

@@ -1337,7 +1337,7 @@ CREATE TRIGGER test_valid_id_trig
   </para>
 
   <para>
-   The return value of the trigger procedure is ignored.
+   The return value of the trigger function is ignored.
   </para>
 
   <para>