12);

CREATE TABLE measurement_ym_y2016m12
    PARTITION OF measurement_year_month
    FOR VALUES FROM (2016, 12) TO (2017, 01);

CREATE TABLE measurement_ym_y2017m01
    PARTITION OF measurement_year_month
    FOR VALUES FROM (2017, 01) TO (2017, 02);
</programlisting></para>

  <para>
   Create partition of a list partitioned table:
<programlisting>
CREATE TABLE cities_ab
    PARTITION OF cities (
    CONSTRAINT city_id_nonzero CHECK (city_id != 0)
) FOR VALUES IN ('a', 'b');
</programlisting></para>

  <para>
   Create partition of a list partitioned table that is itself further
   partitioned and then add a partition to it:
<programlisting>
CREATE TABLE cities_ab
    PARTITION OF cities (
    CONSTRAINT city_id_nonzero CHECK (city_id != 0)
) FOR VALUES IN ('a', 'b') PARTITION BY RANGE (population);

CREATE TABLE cities_ab_10000_to_100000
    PARTITION OF cities_ab FOR VALUES FROM (10000) TO (100000);
</programlisting></para>

  <para>
   Create partitions of a hash partitioned table:
<programlisting>
CREATE TABLE orders_p1 PARTITION OF orders
    FOR VALUES WITH (MODULUS 4, REMAINDER 0);
CREATE TABLE orders_p2 PARTITION OF orders
    FOR VALUES WITH (MODULUS 4, REMAINDER 1);
CREATE TABLE orders_p3 PARTITION OF orders
    FOR VALUES WITH (MODULUS 4, REMAINDER 2);
CREATE TABLE orders_p4 PARTITION OF orders
    FOR VALUES WITH (MODULUS 4, REMAINDER 3);
</programlisting></para>

  <para>
   Create a default partition:
<programlisting>
CREATE TABLE cities_partdef
    PARTITION OF cities DEFAULT;
</programlisting></para>
 </refsect1>

 <refsect1 id="sql-createtable-compatibility" xreflabel="Compatibility">
  <title>Compatibility</title>

  <para>
   The <command>CREATE TABLE</command> command conforms to the
   <acronym>SQL</acronym> standard, with exceptions listed below.
  </para>

  <refsect2>
   <title>Temporary Tables</title>

   <para>
    Although the syntax of <literal>CREATE TEMPORARY TABLE</literal>
    resembles that of the SQL standard, the effect is not the same.  In the
    standard,
    temporary tables are defined just once and automatically exist (starting
    with empty contents) in every session that needs them.
    <productname>PostgreSQL</productname> instead
    requires each session to issue its own <literal>CREATE TEMPORARY
    TABLE</literal> command for each temporary table to be used.  This allows
    different sessions to use the same temporary table name for different
    purposes, whereas the standard's approach constrains all instances of a
    given temporary table name to have the same table structure.
   </para>

   <para>
    The standard's definition of the behavior of temporary tables is
    widely ignored.  <productname>PostgreSQL</productname>'s behavior
    on this point is similar to that of several other SQL databases.
   </para>

   <para>
    The SQL standard also distinguishes between global and local temporary
    tables, where a local temporary table has a separate set of contents for
    each SQL module within each session, though its definition is still shared
    across sessions.  Since <productname>PostgreSQL</productname> does not
    support SQL modules, this distinction is not relevant in
    <productname>PostgreSQL</productname>.
   </para>

   <para>
    For compatibility's sake, <productname>PostgreSQL</productname> will
    accept the <literal>GLOBAL</literal> and <literal>LOCAL</literal> keywords
    in a temporary table declaration, but they currently have no effect.
    Use of these keywords is discouraged, since future versions of
    <productname>PostgreSQL</productname> might adopt a more
    standard-compliant interpretation of their meaning.
   </para>

   <para>
    The <literal>ON COMMIT</literal> clause for temporary tables
    also resembles the SQL standard, but has some differences.
    If the <literal>ON COMMIT</literal> clause is omitted, SQL specifies that the
    default behavior is <literal>ON COMMIT DELETE ROWS</literal>.  However, the
    default behavior