columns in the current table are not allowed).  The
      data type of the default expression must match the data type of the
      column.
     </para>

     <para>
      The default expression will be used in any insert operation that
      does not specify a value for the column.  If there is no default
      for a column, then the default is null.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>GENERATED ALWAYS AS ( <replaceable>generation_expr</replaceable> ) [ STORED | VIRTUAL ]</literal><indexterm><primary>generated column</primary></indexterm></term>
    <listitem>
     <para>
      This clause creates the column as a <firstterm>generated
      column</firstterm>.  The column cannot be written to, and when read the
      result of the specified expression will be returned.
     </para>

     <para>
      When <literal>VIRTUAL</literal> is specified, the column will be
      computed when it is read.  (The foreign-data wrapper will see it as a
      null value in new rows and may choose to store it as a null value or
      ignore it altogether.)  When <literal>STORED</literal> is specified, the
      column will be computed on write.  (The computed value will be presented
      to the foreign-data wrapper for storage and must be returned on
      reading.)  <literal>VIRTUAL</literal> is the default.
     </para>

     <para>
      The generation expression can refer to other columns in the table, but
      not other generated columns.  Any functions and operators used must be
      immutable.  References to other tables are not allowed.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">server_name</replaceable></term>
    <listitem>
     <para>
      The name of an existing foreign server to use for the foreign table.
      For details on defining a server, see <xref
      linkend="sql-createserver"/>.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>OPTIONS ( <replaceable class="parameter">option</replaceable> '<replaceable class="parameter">value</replaceable>' [, ...] )</literal></term>
    <listitem>
     <para>
      Options to be associated with the new foreign table or one of its
      columns.
      The allowed option names and values are specific to each foreign
      data wrapper and are validated using the foreign-data wrapper's
      validator function.  Duplicate option names are not allowed (although
      it's OK for a table option and a column option to have the same name).
     </para>
    </listitem>
   </varlistentry>

  </variablelist>

 </refsect1>

 <refsect1>
  <title>Notes</title>

   <para>
    Constraints on foreign tables (such as <literal>CHECK</literal>
    or <literal>NOT NULL</literal> clauses) are not enforced by the
    core <productname>PostgreSQL</productname> system, and most foreign data wrappers
    do not attempt to enforce them either; that is, the constraint is
    simply assumed to hold true.  There would be little point in such
    enforcement since it would only apply to rows inserted or updated via
    the foreign table, and not to rows modified by other means, such as
    directly on the remote server.  Instead, a constraint attached to a
    foreign table should represent a constraint that is being enforced by
    the remote server.
   </para>

   <para>
    Some special-purpose foreign data wrappers might be the only access
    mechanism for the data they access, and in that case it might be
    appropriate for the foreign data wrapper itself to perform constraint
    enforcement.  But you should not assume that a wrapper does that
    unless its documentation says so.
   </para>

   <para>
    Although <productname>PostgreSQL</productname> does not attempt to enforce
    constraints on foreign tables, it does assume that they are correct