permission is only considered
    safe when used to switch to a domain with a smaller set of privileges than
    the original one. For example:
   </para>
<screen>
regression=# select sepgsql_getcon();
                    sepgsql_getcon
-------------------------------------------------------
 unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
(1 row)

regression=# SELECT sepgsql_setcon('unconfined_u:unconfined_r:unconfined_t:s0-s0:c1.c4');
 sepgsql_setcon
----------------
 t
(1 row)

regression=# SELECT sepgsql_setcon('unconfined_u:unconfined_r:unconfined_t:s0-s0:c1.c1023');
ERROR:  SELinux: security policy violation
</screen>
   <para>
    In this example above we were allowed to switch from the larger MCS
    range <literal>c1.c1023</literal> to the smaller range <literal>c1.c4</literal>, but
    switching back was denied.
   </para>
   <para>
    A combination of dynamic domain transition and trusted procedure
    enables an interesting use case that fits the typical process life-cycle
    of connection pooling software.
    Even if your connection pooling software is not allowed to run most
    of SQL commands, you can allow it to switch the security label
    of the client using the <literal>sepgsql_setcon()</literal> function
    from within a trusted procedure; that should take some
    credential to authorize the request to switch the client label.
    After that, this session will have the privileges of the target user,
    rather than the connection pooler.
    The connection pooler can later revert the security label change by
    again using <literal>sepgsql_setcon()</literal> with
    <literal>NULL</literal> argument, again invoked from within a trusted
    procedure with appropriate permissions checks.
    The point here is that only the trusted procedure actually has permission
    to change the effective security label, and only does so when given proper
    credentials.  Of course, for secure operation, the credential store
    (table, procedure definition, or whatever) must be protected from
    unauthorized access.
   </para>
  </sect3>

  <sect3 id="sepgsql-features-misc">
   <title>Miscellaneous</title>
   <para>
    We reject the <link linkend="sql-load"><command>LOAD</command></link> command across the board, because
    any module loaded could easily circumvent security policy enforcement.
   </para>

  </sect3>
</sect2>

 <sect2 id="sepgsql-functions">
  <title>Sepgsql Functions</title>
  <para>
   <xref linkend="sepgsql-functions-table"/> shows the available functions.
  </para>

  <table id="sepgsql-functions-table">
   <title>Sepgsql Functions</title>
    <tgroup cols="1">
     <thead>
      <row>
       <entry role="func_table_entry"><para role="func_signature">
        Function
       </para>
       <para>
        Description
       </para></entry>
      </row>
     </thead>

     <tbody>
      <row>
       <entry role="func_table_entry"><para role="func_signature">
        <function>sepgsql_getcon</function> ()
        <returnvalue>text</returnvalue>
       </para>
       <para>
        Returns the client domain, the current security label of the client.
       </para></entry>
      </row>

      <row>
       <entry role="func_table_entry"><para role="func_signature">
        <function>sepgsql_setcon</function> ( <type>text</type> )
        <returnvalue>boolean</returnvalue>
       </para>
       <para>
        Switches the client domain of the current session to the new domain,
        if allowed by the security policy.
        It also accepts <literal>NULL</literal> input as a request to transition
        to the client's original domain.
       </para></entry>
      </row>

      <row>
       <entry role="func_table_entry"><para role="func_signature">
        <function>sepgsql_mcstrans_in</function> ( <type>text</type> )
        <returnvalue>text</returnvalue>
       </para>
       <para>
        Translates the given