<programlisting>
typedef bool (*LogicalDecodeFilterByOriginCB) (struct LogicalDecodingContext *ctx,
                                               RepOriginId origin_id);
</programlisting>
      The <parameter>ctx</parameter> parameter has the same contents
      as for the other callbacks. No information but the origin is
      available. To signal that changes originating on the passed in
      node are irrelevant, return true, causing them to be filtered
      away; false otherwise. The other callbacks will not be called
      for transactions and changes that have been filtered away.
     </para>
     <para>
       This is useful when implementing cascading or multidirectional
       replication solutions. Filtering by the origin allows to
       prevent replicating the same changes back and forth in such
       setups.  While transactions and changes also carry information
       about the origin, filtering via this callback is noticeably
       more efficient.
     </para>
     </sect3>

    <sect3 id="logicaldecoding-output-plugin-message">
     <title>Generic Message Callback</title>

     <para>
      The optional <function>message_cb</function> callback is called whenever
      a logical decoding message has been decoded.
<programlisting>
typedef void (*LogicalDecodeMessageCB) (struct LogicalDecodingContext *ctx,
                                        ReorderBufferTXN *txn,
                                        XLogRecPtr message_lsn,
                                        bool transactional,
                                        const char *prefix,
                                        Size message_size,
                                        const char *message);
</programlisting>
      The <parameter>txn</parameter> parameter contains meta information about
      the transaction, like the time stamp at which it has been committed and
      its XID. Note however that it can be NULL when the message is
      non-transactional and the XID was not assigned yet in the transaction
      which logged the message. The <parameter>lsn</parameter> has WAL
      location of the message. The <parameter>transactional</parameter> says
      if the message was sent as transactional or not. Similar to the change
      callback, in case of decoding a prepared (but yet uncommitted)
      transaction or decoding of an uncommitted transaction, this message
      callback might also error out due to simultaneous rollback of
      this very same transaction. In that case, the logical decoding of this
      aborted transaction is stopped gracefully.
      The <parameter>prefix</parameter> is arbitrary null-terminated prefix
      which can be used for identifying interesting messages for the current
      plugin. And finally the <parameter>message</parameter> parameter holds
      the actual message of <parameter>message_size</parameter> size.
     </para>
     <para>
      Extra care should be taken to ensure that the prefix the output plugin
      considers interesting is unique. Using name of the extension or the
      output plugin itself is often a good choice.
     </para>
    </sect3>

    <sect3 id="logicaldecoding-output-plugin-filter-prepare">
     <title>Prepare Filter Callback</title>

     <para>
       The optional <function>filter_prepare_cb</function> callback
       is called to determine whether data that is part of the current
       two-phase commit transaction should be considered for decoding
       at this prepare stage or later as a regular one-phase transaction at
       <command>COMMIT PREPARED</command> time. To signal that
       decoding should be skipped, return <literal>true</literal>;
       <literal>false</literal> otherwise. When the callback is not
       defined, <literal>false</literal> is assumed (i.e. no filtering, all
       transactions using two-phase commit are decoded in two phases as well).
<programlisting>
typedef bool (*LogicalDecodeFilterPrepareCB) (struct LogicalDecodingContext *ctx,