} BrinOpcInfo;

</programlisting>

<structname>BrinOpcInfo</structname>.<structfield>oi_opaque</structfield> can be used by the

operator class routines to pass information between supportprocedures

operator class routines to pass information between supportfunctions

during an index scan.

</para>

</listitem>

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 supportprocedures' source code.

strategies are embedded in the supportfunctions' source code.

</para>

<para>

Operator classes that implement completely different semantics are also

possible, provided implementations of the four main supportprocedures

possible, provided implementations of the four main supportfunctions

described above are written. Note that backwards compatibility across major

releases is not guaranteed: for example, additional supportprocedures might

releases is not guaranteed: for example, additional supportfunctions 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 supportprocedures

ordered set, it is possible to use the minmax supportfunctions

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>

</thead>

<tbody>

<row>

<entry>SupportProcedure 1</entry>

<entry>SupportFunction 1</entry>

<entry>internal function <function>brin_minmax_opcinfo()</function></entry>

</row>

<row>

<entry>SupportProcedure 2</entry>

<entry>SupportFunction 2</entry>

<entry>internal function <function>brin_minmax_add_value()</function></entry>

</row>

<row>

<entry>SupportProcedure 3</entry>

<entry>SupportFunction 3</entry>

<entry>internal function <function>brin_minmax_consistent()</function></entry>

</row>

<row>

<entry>SupportProcedure 4</entry>

<entry>SupportFunction 4</entry>

<entry>internal function <function>brin_minmax_union()</function></entry>

</row>

<row>

<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

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

</thead>

<tbody>

<row>

<entry>SupportProcedure 1</entry>

<entry>SupportFunction 1</entry>

<entry>internal function <function>brin_inclusion_opcinfo()</function></entry>

<entry></entry>

</row>

<row>

<entry>SupportProcedure 2</entry>

<entry>SupportFunction 2</entry>

<entry>internal function <function>brin_inclusion_add_value()</function></entry>

<entry></entry>

</row>

<row>

<entry>SupportProcedure 3</entry>

<entry>SupportFunction 3</entry>

<entry>internal function <function>brin_inclusion_consistent()</function></entry>

<entry></entry>

</row>

<row>

<entry>SupportProcedure 4</entry>

<entry>SupportFunction 4</entry>

<entry>internal function <function>brin_inclusion_union()</function></entry>

<entry></entry>

</row>

<row>

<entry>SupportProcedure 11</entry>

<entry>SupportFunction 11</entry>

<entry>function to merge two elements</entry>

<entry></entry>

</row>

<row>

<entry>SupportProcedure 12</entry>

<entry>SupportFunction 12</entry>

<entry>optional function to check whether two elements are mergeable</entry>

<entry></entry>

</row>

<row>

<entry>SupportProcedure 13</entry>

<entry>SupportFunction 13</entry>

<entry>optional function to check if an element is contained within another</entry>

<entry></entry>

</row>

<row>

<entry>SupportProcedure 14</entry>

<entry>SupportFunction 14</entry>

<entry>optional function to check whether an element is empty</entry>

<entry></entry>

</row>

</table>

<para>

Supportprocedure numbers 1-10 are reserved for the BRIN internal

Supportfunction 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,

</para>

<para>

Supportprocedure numbers 12 and 14 are provided to support

irregularities of built-in data types.Procedure number 12

Supportfunction 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

<row>

<entry><link linkend="catalog-pg-amproc"><structname>pg_amproc</structname></link></entry>

<entry>access method supportprocedures</entry>

<entry>access method supportfunctions</entry>

</row>

<row>

<para>

The catalog <structname>pg_amproc</structname> stores information about

supportprocedures associated with access method operator families. There

is one row for each supportprocedure belonging to an operator family.

supportfunctions associated with access method operator families. There

is one row for each supportfunction belonging to an operator family.

</para>

<table>

<entry><structfield>amprocnum</structfield></entry>

<entry><type>int2</type></entry>

<entry></entry>

<entry>Supportprocedure number</entry>

<entry>Supportfunction 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 theprocedure</entry>

<entry>OID of thefunction</entry>

</row>

</tbody>

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 supportprocedure supports. For some access methods

these match the input data type(s) of the supportprocedure itself, for

others not. There is a notion of <quote>default</quote> supportprocedures for

that a particular supportfunction supports. For some access methods

these match the input data type(s) of the supportfunction itself, for

others not. There is a notion of <quote>default</quote> supportfunctions 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>.

<para>

The catalog <structname>pg_conversion</structname> describes

encoding conversionprocedures. See <xref linkend="sql-createconversion"/>

encoding conversionfunctions. See <xref linkend="sql-createconversion"/>

for more information.

</para>

<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>Conversionprocedure</entry>

<entry>Conversionfunction</entry>

</row>

<row>

<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);

<tip>

<para>

If your needs go beyond the capabilities of these conditional

expressions, you might want to consider writing astored procedure

expressions, you might want to consider writing aserver-side function

in a more expressive programming language.

</para>

</tip>

if (CALLED_AS_TRIGGER(fcinfo))

{

/*

* Called as a triggerprocedure

* Called as a triggerfunction

*/

TriggerData *trigdata = (TriggerData *) fcinfo-&gt;context;

</para>

<para>

The return value of the triggerprocedure is ignored.

The return value of the triggerfunction is ignored.

</para>

<para>