Other kinds of foreign data
    wrappers might be found as third party products.  If none of the existing
    foreign data wrappers suit your needs, you can write your own; see <xref
    linkend="fdwhandler"/>.
   </para>

   <para>
    To access foreign data, you need to create a <firstterm>foreign server</firstterm>
    object, which defines how to connect to a particular external data source
    according to the set of options used by its supporting foreign data
    wrapper. Then you need to create one or more <firstterm>foreign
    tables</firstterm>, which define the structure of the remote data. A
    foreign table can be used in queries just like a normal table, but a
    foreign table has no storage in the PostgreSQL server.  Whenever it is
    used, <productname>PostgreSQL</productname> asks the foreign data wrapper
    to fetch data from the external source, or transmit data to the external
    source in the case of update commands.
   </para>

   <para>
    Accessing remote data may require authenticating to the external
    data source.  This information can be provided by a
    <firstterm>user mapping</firstterm>, which can provide additional data
    such as user names and passwords based
    on the current <productname>PostgreSQL</productname> role.
   </para>

   <para>
    For additional information, see
    <xref linkend="sql-createforeigndatawrapper"/>,
    <xref linkend="sql-createserver"/>,
    <xref linkend="sql-createusermapping"/>,
    <xref linkend="sql-createforeigntable"/>, and
    <xref linkend="sql-importforeignschema"/>.
   </para>
 </sect1>

 <sect1 id="ddl-others">
  <title>Other Database Objects</title>

  <para>
   Tables are the central objects in a relational database structure,
   because they hold your data.  But they are not the only objects
   that exist in a database.  Many other kinds of objects can be
   created to make the use and management of the data more efficient
   or convenient.  They are not discussed in this chapter, but we give
   you a list here so that you are aware of what is possible:
  </para>

  <itemizedlist>
   <listitem>
    <para>
     Views
    </para>
   </listitem>

   <listitem>
    <para>
     Functions, procedures, and operators
    </para>
   </listitem>

   <listitem>
    <para>
     Data types and domains
    </para>
   </listitem>

   <listitem>
    <para>
     Triggers and rewrite rules
    </para>
   </listitem>
  </itemizedlist>

  <para>
   Detailed information on
   these topics appears in <xref linkend="server-programming"/>.
  </para>
 </sect1>

 <sect1 id="ddl-depend">
  <title>Dependency Tracking</title>

  <indexterm zone="ddl-depend">
   <primary>CASCADE</primary>
   <secondary sortas="DROP">with DROP</secondary>
  </indexterm>

  <indexterm zone="ddl-depend">
   <primary>RESTRICT</primary>
   <secondary sortas="DROP">with DROP</secondary>
  </indexterm>

  <para>
   When you create complex database structures involving many tables
   with foreign key constraints, views, triggers, functions, etc. you
   implicitly create a net of dependencies between the objects.
   For instance, a table with a foreign key constraint depends on the
   table it references.
  </para>

  <para>
   To ensure the integrity of the entire database structure,
   <productname>PostgreSQL</productname> makes sure that you cannot
   drop objects that other objects still depend on.  For example,
   attempting to drop the products table we considered in <xref
   linkend="ddl-constraints-fk"/>, with the orders table depending on
   it, would result in an error message like this:
<screen>
DROP TABLE products;

ERROR:  cannot drop table products because other objects depend on it
DETAIL:  constraint orders_product_no_fkey on table orders depends on table products
HINT:  Use DROP ... CASCADE to drop the dependent objects too.
</screen>
   The error message contains a useful hint: if you do not want to
   bother deleting all the dependent objects individually, you can