Brief note about sequence cache not being cleared in other backends.

Actually clear the cache in the backend making the alteration.  This
follows in the footsteps of setval().

Rod Taylor

2 files changed, 30 insertions, 3 deletions

diff --git a/doc/src/sgml/ref/alter_sequence.sgml b/doc/src/sgml/ref/alter_sequence.sgml
index c6c3a7e33c..28a81022aa 100644
--- a/doc/src/sgml/ref/alter_sequence.sgml
+++ b/doc/src/sgml/ref/alter_sequence.sgml
@@ -1,5 +1,5 @@
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/ref/alter_sequence.sgml,v 1.1 2003/03/20 07:02:07 momjian Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/ref/alter_sequence.sgml,v 1.2 2003/06/12 07:49:43 momjian Exp $
 PostgreSQL documentation
 -->
 
@@ -236,6 +236,12 @@ ALTER SEQUENCE serial RESTART WITH 105;
    later aborts. This means that aborted transactions may leave unused "holes" in
    the sequence of assigned values. setval operations are never rolled back, either.
   </para>
+  <para>
+   <command>ALTER SEQUENCE</command> will not immediately affect backends, other than the
+   current one, which have cached sequence values. They must use up all cached values
+   prior to noticing the changed sequence parameters.  The current backend will be 
+   immediatly affected.
+  </para>
  </refsect1>
 
 
diff --git a/doc/src/sgml/ref/create_table.sgml b/doc/src/sgml/ref/create_table.sgml
index 9a29b645aa..2a33de6dfb 100644
--- a/doc/src/sgml/ref/create_table.sgml
+++ b/doc/src/sgml/ref/create_table.sgml
@@ -1,5 +1,5 @@
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_table.sgml,v 1.68 2003/05/04 00:03:55 tgl Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_table.sgml,v 1.69 2003/06/12 07:49:43 momjian Exp $
 PostgreSQL documentation
 -->
 
@@ -18,7 +18,8 @@ PostgreSQL documentation
 <synopsis>
 CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } ] TABLE <replaceable class="PARAMETER">table_name</replaceable> (
     { <replaceable class="PARAMETER">column_name</replaceable> <replaceable class="PARAMETER">data_type</replaceable> [ DEFAULT <replaceable>default_expr</> ] [ <replaceable class="PARAMETER">column_constraint</replaceable> [, ... ] ]
-    | <replaceable>table_constraint</replaceable> }  [, ... ]
+    | <replaceable>table_constraint</replaceable>
+    | LIKE <replaceable>parent_table</replaceable> [ { INCLUDING | EXCLUDING } DEFAULTS ] }  [, ... ]
 )
 [ INHERITS ( <replaceable>parent_table</replaceable> [, ... ] ) ]
 [ WITH OIDS | WITHOUT OIDS ]
@@ -173,6 +174,26 @@ and <replaceable class="PARAMETER">table_constraint</replaceable> is:
    </varlistentry>
 
    <varlistentry>
+    <term><literal>LIKE <replaceable>parent_table</replaceable> [ { INCLUDING | EXCLUDING } DEFAULTS ]</literal></term>
+    <listitem>
+     <para>
+      The <literal>LIKE</literal> clause specifies a table from which
+      the new table automatically inherits all column names, their datatypes, and
+      <literal>NOT NULL</literal> constraints.
+     </para>
+     <para>
+      Unlike <literal>INHERITS</literal>, the new table and inherited table
+      are complete decoupled after creation has been completed.  Data inserted
+      into the new table will not be reflected into the parent table.
+     </para>
+     <para>
+      Default expressions for the inherited column definitions will only be included if
+      <literal>INCLUDING DEFAULTS</literal> is specified.  The default is to exclude
+      default expressions.
+    </listitem>
+   </varlistentry>
+
+   <varlistentry>
     <term><literal>INHERITS ( <replaceable>parent_table</replaceable> [, ... ] )</literal></term>
     <listitem>
      <para>