Index: doc/src/sgml/ddl.sgml
===================================================================
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ddl.sgml,v
retrieving revision 1.77
diff -c -r1.77 ddl.sgml
*** doc/src/sgml/ddl.sgml	28 Nov 2007 15:42:31 -0000	1.77
--- doc/src/sgml/ddl.sgml	28 Nov 2007 20:23:44 -0000
***************
*** 2510,2564 ****
        <listitem>
         <para>
          If data will be added only to the latest partition, we can
!         set up a very simple rule to insert data. We must
!         redefine this each month so that it always points to the
!         current partition:
! 
! <programlisting>
! CREATE OR REPLACE RULE measurement_current_partition AS
! ON INSERT TO measurement
! DO INSTEAD
!     INSERT INTO measurement_y2006m01 VALUES ( NEW.city_id,
!                                               NEW.logdate,
!                                               NEW.peaktemp,
!                                               NEW.unitsales );
  </programlisting>
  
          We might want to insert data and have the server automatically
          locate the partition into which the row should be added. We
!         could do this with a more complex set of rules as shown below:
  
  <programlisting>
! CREATE RULE measurement_insert_y2004m02 AS
! ON INSERT TO measurement WHERE
!     ( logdate &gt;= DATE '2004-02-01' AND logdate &lt; DATE '2004-03-01' )
! DO INSTEAD
!     INSERT INTO measurement_y2004m02 VALUES ( NEW.city_id,
!                                               NEW.logdate,
!                                               NEW.peaktemp,
!                                               NEW.unitsales );
! ...
! CREATE RULE measurement_insert_y2005m12 AS
! ON INSERT TO measurement WHERE
!     ( logdate &gt;= DATE '2005-12-01' AND logdate &lt; DATE '2006-01-01' )
! DO INSTEAD
!     INSERT INTO measurement_y2005m12 VALUES ( NEW.city_id,
!                                               NEW.logdate,
!                                               NEW.peaktemp,
!                                               NEW.unitsales );
! CREATE RULE measurement_insert_y2006m01 AS
! ON INSERT TO measurement WHERE
!     ( logdate &gt;= DATE '2006-01-01' AND logdate &lt; DATE '2006-02-01' )
! DO INSTEAD
!     INSERT INTO measurement_y2006m01 VALUES ( NEW.city_id,
!                                               NEW.logdate,
!                                               NEW.peaktemp,
!                                               NEW.unitsales );
! </programlisting>
! 
!         Note that the <literal>WHERE</literal> clause in each rule
!         exactly matches the <literal>CHECK</literal>
!         constraint for its partition.
         </para>
        </listitem>
       </orderedlist>
--- 2510,2589 ----
        <listitem>
         <para>
          If data will be added only to the latest partition, we can
!         set up a very simple trigger function to insert data.  We must
!         redefine this each month so that it always points to the current
!         partition:
! 
! <programlisting>
! CREATE OR REPLACE FUNCTION measurement_current_partition()
! RETURNS TRIGGER
! LANGUAGE plpgsql
! AS $$
! BEGIN
!     INSERT INTO measurement_y2006m01
!     VALUES (
!         NEW.city_id,
!         NEW.logdate,
!         NEW.peaktemp,
!         NEW.unitsales
!     );
!     RETURN NEW;
! END;
! $$;
! </programlisting>
! 
!         The first time we create the table, we create a trigger which
!         calls the above trigger function.  When we replace the trigger
!         function, we don't need to replace the trigger.
! 
! <programlisting>
! CREATE TRIGGER insert_measurement_current_partition
!     BEFORE INSERT
!     ON measurement
!     EXECUTE PROCEDURE measurement_current_partition();
  </programlisting>
  
          We might want to insert data and have the server automatically
          locate the partition into which the row should be added. We
!         could do this with a more complex trigger function as shown
!         below:
  
  <programlisting>
! CREATE OR REPLACE FUNCTION measurement_insert()
! RETURNS TRIGGER
! LANGUAGE plpgsql
! AS $$
! BEGIN
!     IF ( logdate &gt;= DATE '2004-02-01' AND logdate &lt; DATE '2004-03-01' ) THEN
! 
!         INSERT INTO measurement_y2004m02
!         VALUES (
!             NEW.city_id,
!             NEW.logdate,
!             NEW.peaktemp,
!             NEW.unitsales
!         );
!     ELSIF ( logdate &gt;= DATE '2005-12-01' AND logdate &lt; DATE '2006-01-01' ) THEN
!     ...
!     ELSIF ( logdate &gt;= DATE '2008-01-01' AND logdate &lt; DATE '2006-02-01' ) THEN
!         INSERT INTO measurement_y2008m01
!         VALUES (
!             NEW.city_id,
!             NEW.logdate,
!             NEW.peaktemp,
!             NEW.unitsales
!         );
!     ELSE
!         RAISE EXCEPTION 'In, measurement_insert(), the date out of range.  Fix the trigger function!';
!     END IF;
!     RETURN NULL;
! END;
! $$;
! </programlisting>
! 
!         Note that the <literal>WHERE</literal> clause in each section
!         of the trigger function exactly matches the
!         <literal>CHECK</literal> constraint for its partition.
         </para>
        </listitem>
       </orderedlist>
***************
*** 2568,2574 ****
       As we can see, a complex partitioning scheme could require a
       substantial amount of DDL. In the above example we would be
       creating a new partition each month, so it might be wise to write a
!      script that generates the required DDL automatically.
      </para>
  
     <para>
--- 2593,2601 ----
       As we can see, a complex partitioning scheme could require a
       substantial amount of DDL. In the above example we would be
       creating a new partition each month, so it might be wise to write a
!      script that generates the required DDL automatically.  You could
!      also write a function to determine the partition dynamically
!      before doing the INSERT.
      </para>
  
     <para>