Stream triggers manipulation interfaces
=======================================

You can create stream triggers only on tables with
``REPLICA IDENTITY FULL`` or tables without any columns to which
``TOAST`` applies.

bdr.create_conflict_trigger
---------------------------

This function creates a new conflict trigger.

Synopsis
^^^^^^^^

.. code:: sql

   bdr.create_conflict_trigger(trigger_name text,
                               events text[],
                               relation regclass,
                               function regprocedure,
                               args text[] DEFAULT {})

Parameters
^^^^^^^^^^

-  ``trigger_name`` — Name of the new trigger.

-  ``events`` — Array of events on which to fire this trigger. Valid
   values are ‘``INSERT``’, ‘``UPDATE``’, and ‘``DELETE``’.

-  ``relation`` — Relation to fire this trigger for.

-  ``function`` — The function to execute.

-  ``args`` — Optional. Specifies the array of parameters the trigger
   function receives on execution (contents of ``TG_ARGV`` variable).

Notes
^^^^^

This function uses the same replication mechanism as ``DDL`` statements.
This means that the replication is affected by the :ref:`ddl filters <Replication sets>` 
configuration.

The function takes a global DML lock on the relation on which the
trigger is being created.

This function is transactional. You can roll back the effects with the
``ROLLBACK`` of the transaction. The changes are visible to the current
transaction.

Similar to normal PostgreSQL triggers, the
``bdr.create_conflict_trigger`` function requires ``TRIGGER`` privilege
on the ``relation`` and ``EXECUTE`` privilege on the function. This
applies with a ``bdr.backwards_compatibility`` of 30619 or above.
Additional security rules apply in PGD to all triggers including
conflict triggers. See :ref:`Security and roles <Security and roles>`  .

bdr.create_transform_trigger
----------------------------

This function creates a transform trigger.

.. _synopsis-1:

Synopsis
^^^^^^^^

.. code:: sql

   bdr.create_transform_trigger(trigger_name text,
                                events text[],
                                relation regclass,
                                function regprocedure,
                                args text[] DEFAULT {})

.. _parameters-1:

Parameters
^^^^^^^^^^

-  ``trigger_name`` — Name of the new trigger.

-  ``events`` — Array of events on which to fire this trigger. Valid
   values are ‘``INSERT``’, ‘``UPDATE``’, and ‘``DELETE``’.

-  ``relation`` — Relation to fire this trigger for.

-  ``function`` — The function to execute.

-  ``args`` — Optional. Specify array of parameters the trigger function
   receives on execution (contents of ``TG_ARGV`` variable).

.. _notes-1:

Notes
^^^^^

This function uses the same replication mechanism as ``DDL`` statements.
This means that the replication is affected by the :ref:`ddl filters <Replication sets>` 
configuration.

The function takes a global DML lock on the relation on which the
trigger is being created.

This function is transactional. You can roll back the effects with the
``ROLLBACK`` of the transaction. The changes are visible to the current
transaction.

Similarly to normal PostgreSQL triggers, the
``bdr.create_transform_trigger`` function requires the ``TRIGGER``
privilege on the ``relation`` and ``EXECUTE`` privilege on the function.
Additional security rules apply in PGD to all triggers including
transform triggers. See :ref:`Security and roles <Security and roles>`  .

bdr.drop_trigger
----------------

This function removes an existing stream trigger (both conflict and
transform).

.. _synopsis-2:

Synopsis
^^^^^^^^

.. code:: sql

   bdr.drop_trigger(trigger_name text,
                    relation regclass,
                    ifexists boolean DEFAULT false)

.. _parameters-2:

Parameters
^^^^^^^^^^

-  ``trigger_name`` — Name of an existing trigger.

-  ``relation`` — The relation the trigger is defined for.

-  ``ifexists`` — When set to ``true`` , this function ignores missing
   triggers.

.. _notes-2:

Notes
^^^^^

This function uses the same replication mechanism as ``DDL`` statements.
This means that the replication is affected by the :ref:`ddl filters <Replication sets>` 
configuration.

The function takes a global DML lock on the relation on which the
trigger is being created.

This function is transactional. You can roll back the effects with the
``ROLLBACK`` of the transaction. The changes are visible to the current
transaction.

Only the owner of the ``relation`` can execute the ``bdr.drop_trigger``
function.