<function>stream_commit_cb</function>, and <function>stream_change_cb</function>
     are required, while <function>stream_message_cb</function> and
     <function>stream_truncate_cb</function> are optional. The
     <function>stream_prepare_cb</function> is also required if the output
     plugin also support two-phase commits.
    </para>

    <para>
    An output plugin may also define functions to support two-phase commits,
    which allows actions to be decoded on the <command>PREPARE TRANSACTION</command>.
    The <function>begin_prepare_cb</function>, <function>prepare_cb</function>,
    <function>commit_prepared_cb</function> and <function>rollback_prepared_cb</function>
    callbacks are required, while <function>filter_prepare_cb</function> is optional.
    The <function>stream_prepare_cb</function> is also required if the output plugin
    also supports the streaming of large in-progress transactions.
    </para>
   </sect2>

   <sect2 id="logicaldecoding-capabilities">
    <title>Capabilities</title>

    <para>
     To decode, format and output changes, output plugins can use most of the
     backend's normal infrastructure, including calling output functions. Read
     only access to relations is permitted as long as only relations are
     accessed that either have been created by <command>initdb</command> in
     the <literal>pg_catalog</literal> schema, or have been marked as user
     provided catalog tables using
<programlisting>
ALTER TABLE user_catalog_table SET (user_catalog_table = true);
CREATE TABLE another_catalog_table(data text) WITH (user_catalog_table = true);
</programlisting>
     Note that access to user catalog tables or regular system catalog tables
     in the output plugins has to be done via the <literal>systable_*</literal>
     scan APIs only. Access via the <literal>heap_*</literal> scan APIs will
     error out. Additionally, any actions leading to transaction ID assignment
     are prohibited. That, among others, includes writing to tables, performing
     DDL changes, and calling <literal>pg_current_xact_id()</literal>.
    </para>
   </sect2>

   <sect2 id="logicaldecoding-output-mode">
    <title>Output Modes</title>

    <para>
     Output plugin callbacks can pass data to the consumer in nearly arbitrary
     formats. For some use cases, like viewing the changes via SQL, returning
     data in a data type that can contain arbitrary data (e.g., <type>bytea</type>) is
     cumbersome. If the output plugin only outputs textual data in the
     server's encoding, it can declare that by
     setting <literal>OutputPluginOptions.output_type</literal>
     to <literal>OUTPUT_PLUGIN_TEXTUAL_OUTPUT</literal> instead
     of <literal>OUTPUT_PLUGIN_BINARY_OUTPUT</literal> in
     the <link linkend="logicaldecoding-output-plugin-startup">startup
     callback</link>. In that case, all the data has to be in the server's encoding
     so that a <type>text</type> datum can contain it. This is checked in assertion-enabled
     builds.
    </para>
   </sect2>

   <sect2 id="logicaldecoding-output-plugin-callbacks">
    <title>Output Plugin Callbacks</title>

    <para>
     An output plugin gets notified about changes that are happening via
     various callbacks it needs to provide.
    </para>

    <para>
     Concurrent transactions are decoded in commit order, and only changes
     belonging to a specific transaction are decoded between
     the <literal>begin</literal> and <literal>commit</literal>
     callbacks. Transactions that were rolled back explicitly or implicitly
     never get
     decoded. Successful savepoints are
     folded into the transaction containing them in the order they were
     executed within that transaction. A transaction that is prepared for
     a two-phase commit using <command>PREPARE TRANSACTION</command> will
     also be decoded if the output plugin callbacks needed for decoding
     them are provided. It is possible that the current prepared transaction