DROP SCHEMA myschema CASCADE;
</programlisting>
    See <xref linkend="ddl-depend"/> for a description of the general
    mechanism behind this.
   </para>

   <para>
    Often you will want to create a schema owned by someone else
    (since this is one of the ways to restrict the activities of your
    users to well-defined namespaces).  The syntax for that is:
<programlisting>
CREATE SCHEMA <replaceable>schema_name</replaceable> AUTHORIZATION <replaceable>user_name</replaceable>;
</programlisting>
    You can even omit the schema name, in which case the schema name
    will be the same as the user name.  See <xref
    linkend="ddl-schemas-patterns"/> for how this can be useful.
   </para>

   <para>
    Schema names beginning with <literal>pg_</literal> are reserved for
    system purposes and cannot be created by users.
   </para>
  </sect2>

  <sect2 id="ddl-schemas-public">
   <title>The Public Schema</title>

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

   <para>
    In the previous sections we created tables without specifying any
    schema names.  By default such tables (and other objects) are
    automatically put into a schema named <quote>public</quote>.  Every new
    database contains such a schema.  Thus, the following are equivalent:
<programlisting>
CREATE TABLE products ( ... );
</programlisting>
    and:
<programlisting>
CREATE TABLE public.products ( ... );
</programlisting>
   </para>
  </sect2>

  <sect2 id="ddl-schemas-path">
   <title>The Schema Search Path</title>

   <indexterm>
    <primary>search path</primary>
   </indexterm>

   <indexterm>
    <primary>unqualified name</primary>
   </indexterm>

   <indexterm>
    <primary>name</primary>
    <secondary>unqualified</secondary>
   </indexterm>

   <para>
    Qualified names are tedious to write, and it's often best not to
    wire a particular schema name into applications anyway.  Therefore
    tables are often referred to by <firstterm>unqualified names</firstterm>,
    which consist of just the table name.  The system determines which table
    is meant by following a <firstterm>search path</firstterm>, which is a list
    of schemas to look in.  The first matching table in the search path
    is taken to be the one wanted.  If there is no match in the search
    path, an error is reported, even if matching table names exist
    in other schemas in the database.
   </para>

  <para>
    The ability to create like-named objects in different schemas complicates
    writing a query that references precisely the same objects every time.  It
    also opens up the potential for users to change the behavior of other
    users' queries, maliciously or accidentally.  Due to the prevalence of
    unqualified names in queries and their use
    in <productname>PostgreSQL</productname> internals, adding a schema
    to <varname>search_path</varname> effectively trusts all users having
    <literal>CREATE</literal> privilege on that schema.  When you run an
    ordinary query, a malicious user able to create objects in a schema of
    your search path can take control and execute arbitrary SQL functions as
    though you executed them.
   </para>

   <indexterm>
    <primary>schema</primary>
    <secondary>current</secondary>
   </indexterm>

   <para>
    The first schema named in the search path is called the current schema.
    Aside from being the first schema searched, it is also the schema in
    which new tables will be created if the <command>CREATE TABLE</command>
    command does not specify a schema name.
   </para>

   <indexterm>
    <primary><varname>search_path</varname> configuration parameter</primary>
   </indexterm>

   <para>
    To show the current search path, use the following command:
<programlisting>
SHOW search_path;
</programlisting>
    In the default setup this returns:
<screen>
 search_path
--------------
 "$user", public
</screen>
    The first element