<para>
      Internal query: the text of a failed internally-generated command.
      This could be, for example, an SQL query issued by a PL/pgSQL function.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>W</literal></term>
    <listitem>
     <para>
      Where: an indication of the context in which the error occurred.
      Presently this includes a call stack traceback of active
      procedural language functions and internally-generated queries.
      The trace is one entry per line, most recent first.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>s</literal></term>
    <listitem>
     <para>
      Schema name: if the error was associated with a specific database
      object, the name of the schema containing that object, if any.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>t</literal></term>
    <listitem>
     <para>
      Table name: if the error was associated with a specific table, the
      name of the table.  (Refer to the schema name field for the name of
      the table's schema.)
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>c</literal></term>
    <listitem>
     <para>
      Column name: if the error was associated with a specific table column,
      the name of the column.  (Refer to the schema and table name fields to
      identify the table.)
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>d</literal></term>
    <listitem>
     <para>
      Data type name: if the error was associated with a specific data type,
      the name of the data type.  (Refer to the schema name field for the
      name of the data type's schema.)
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>n</literal></term>
    <listitem>
     <para>
      Constraint name: if the error was associated with a specific
      constraint, the name of the constraint.  Refer to fields listed above
      for the associated table or domain.  (For this purpose, indexes are
      treated as constraints, even if they weren't created with constraint
      syntax.)
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>F</literal></term>
    <listitem>
     <para>
      File: the file name of the source-code location where the error
      was reported.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>L</literal></term>
    <listitem>
     <para>
      Line: the line number of the source-code location where the error
      was reported.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>R</literal></term>
    <listitem>
     <para>
      Routine: the name of the source-code routine reporting the error.
     </para>
    </listitem>
   </varlistentry>
  </variablelist>

  <note>
   <para>
    The fields for schema name, table name, column name, data type name, and
    constraint name are supplied only for a limited number of error types;
    see <xref linkend="errcodes-appendix"/>.  Frontends should not assume that
    the presence of any of these fields guarantees the presence of another
    field.  Core error sources observe the interrelationships noted above, but
    user-defined functions may use these fields in other ways.  In the same
    vein, clients should not assume that these fields denote contemporary
    objects in the current database.
   </para>
  </note>

  <para>
   The client is responsible for formatting displayed information to meet its
   needs; in particular it should break long lines as needed.  Newline characters
   appearing in the error message fields should be treated as paragraph breaks,
   not line breaks.
  </para>
 </sect1>

 <sect1 id="protocol-logicalrep-message-formats">
  <title>Logical Replication Message Formats</title>

  <para>
   This section describes the detailed format of each logical