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.