of <literal>mallory</literal>'s privilege level and allows her to see the
   updated row.
  </para>

  <para>
   There are several ways around this problem.  One simple answer is to use
   <literal>SELECT ... FOR SHARE</literal> in sub-<command>SELECT</command>s in row
   security policies.  However, that requires granting <literal>UPDATE</literal>
   privilege on the referenced table (here <structname>users</structname>) to the
   affected users, which might be undesirable.  (But another row security
   policy could be applied to prevent them from actually exercising that
   privilege; or the sub-<command>SELECT</command> could be embedded into a security
   definer function.)  Also, heavy concurrent use of row share locks on the
   referenced table could pose a performance problem, especially if updates
   of it are frequent.  Another solution, practical if updates of the
   referenced table are infrequent, is to take an
   <literal>ACCESS EXCLUSIVE</literal> lock on the
   referenced table when updating it, so that no concurrent transactions
   could be examining old row values.  Or one could just wait for all
   concurrent transactions to end after committing an update of the
   referenced table and before making changes that rely on the new security
   situation.
  </para>

  <para>
   For additional details see <xref linkend="sql-createpolicy"/>
   and <xref linkend="sql-altertable"/>.
  </para>

 </sect1>

 <sect1 id="ddl-schemas">
  <title>Schemas</title>

  <indexterm zone="ddl-schemas">
   <primary>schema</primary>
  </indexterm>

  <para>
   A <productname>PostgreSQL</productname> database cluster contains
   one or more named databases.  Roles and a few other object types are
   shared across the entire cluster.  A client connection to the server
   can only access data in a single database, the one specified in the
   connection request.
  </para>

  <note>
   <para>
    Users of a cluster do not necessarily have the privilege to access every
    database in the cluster.  Sharing of role names means that there
    cannot be different roles named, say, <literal>joe</literal> in two databases
    in the same cluster; but the system can be configured to allow
    <literal>joe</literal> access to only some of the databases.
   </para>
  </note>

  <para>
   A database contains one or more named <firstterm>schemas</firstterm>, which
   in turn contain tables.  Schemas also contain other kinds of named
   objects, including data types, functions, and operators.  Within one
   schema, two objects of the same type cannot have the same name.
   Furthermore, tables, sequences, indexes, views, materialized views, and
   foreign tables share the same namespace, so that, for example, an index and
   a table must have different names if they are in the same schema.  The same
   object name can be used in different schemas without conflict; for
   example, both <literal>schema1</literal> and <literal>myschema</literal> can
   contain tables named <literal>mytable</literal>.  Unlike databases,
   schemas are not rigidly separated: a user can access objects in any
   of the schemas in the database they are connected to, if they have
   privileges to do so.
  </para>

  <para>
   There are several reasons why one might want to use schemas:

   <itemizedlist>
    <listitem>
     <para>
      To allow many users to use one database without interfering with
      each other.
     </para>
    </listitem>

    <listitem>
     <para>
      To organize database objects into logical groups to make them
      more manageable.
     </para>
    </listitem>

    <listitem>
     <para>
      Third-party applications can be put into separate schemas so
      they do not collide with the names of other objects.
     </para>
    </listitem>
   </itemizedlist>

   Schemas are analogous to directories at the operating system level,
   except that schemas cannot be nested.
  </para>

  <sect2 id="ddl-schemas-create">
   <title>Creating a Schema</title>