its installation and update scripts.  It is not terribly difficult for
     a malicious user to create trojan-horse objects that will compromise
     later execution of a carelessly-written extension script, allowing that
     user to acquire superuser privileges.
    </para>

    <para>
     If an extension is marked <varname>trusted</varname>, then its
     installation schema can be selected by the installing user, who might
     intentionally use an insecure schema in hopes of gaining superuser
     privileges.  Therefore, a trusted extension is extremely exposed from a
     security standpoint, and all its script commands must be carefully
     examined to ensure that no compromise is possible.
    </para>

    <para>
     Advice about writing functions securely is provided in
     <xref linkend="extend-extensions-security-funcs"/> below, and advice
     about writing installation scripts securely is provided in
     <xref linkend="extend-extensions-security-scripts"/>.
    </para>

    <sect3 id="extend-extensions-security-funcs">
     <title>Security Considerations for Extension Functions</title>

     <para>
      SQL-language and PL-language functions provided by extensions are at
      risk of search-path-based attacks when they are executed, since
      parsing of these functions occurs at execution time not creation time.
     </para>

     <para>
      The <link linkend="sql-createfunction-security"><command>CREATE
      FUNCTION</command></link> reference page contains advice about
      writing <literal>SECURITY DEFINER</literal> functions safely.  It's
      good practice to apply those techniques for any function provided by
      an extension, since the function might be called by a high-privilege
      user.
     </para>

     <!-- XXX It's not enough to use qualified names, because one might write a
          qualified name to an object that itself uses unqualified names.  Many
          information_schema functions have that defect, for example.  However,
          that's a defect in the referenced object, and relatively few queries
          will be affected.  Also, we direct applications to secure search_path
          when connecting to an untrusted database; if applications do that,
          they are immune to known attacks even if some extension refers to a
          defective object.  Therefore, guide extension authors as though core
          PostgreSQL contained no such defect. -->
     <para>
      If you cannot set the <varname>search_path</varname> to contain only
      secure schemas, assume that each unqualified name could resolve to an
      object that a malicious user has defined.  Beware of constructs that
      depend on <varname>search_path</varname> implicitly; for
      example, <token>IN</token>
      and <literal>CASE <replaceable>expression</replaceable> WHEN</literal>
      always select an operator using the search path.  In their place, use
      <literal>OPERATOR(<replaceable>schema</replaceable>.=) ANY</literal>
      and <literal>CASE WHEN <replaceable>expression</replaceable></literal>.
     </para>

     <para>
      A general-purpose extension usually should not assume that it's been
      installed into a secure schema, which means that even schema-qualified
      references to its own objects are not entirely risk-free.  For
      example, if the extension has defined a
      function <literal>myschema.myfunc(bigint)</literal> then a call such
      as <literal>myschema.myfunc(42)</literal> could be captured by a
      hostile function <literal>myschema.myfunc(integer)</literal>.  Be
      careful that the data types of function and operator parameters exactly
      match the declared argument types, using explicit casts where necessary.
     </para>
    </sect3>

    <sect3 id="extend-extensions-security-scripts">
     <title>Security Considerations for Extension Scripts</title>

     <para>
      An extension installation or update script should be written to guard