Remove tabs from SGML file.

diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 0aaf4c1b480cbad9f2b5e79cf200baec1ce53b98..e272b8b6ee3acb5951677d11d4a8b7b43c315954 100644 (file)
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/func.sgml,v 1.453 2008/11/03 20:17:20 adunstan Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/func.sgml,v 1.454 2008/11/04 00:59:45 momjian Exp $ -->
 
  <chapter id="functions">
   <title>Functions and Operators</title>
@@ -12855,46 +12855,46 @@ SELECT (pg_stat_file('filename')).modification;
 
    <para>
       Currently <productname>PostgreSQL</> provides one built in trigger
-         function, <function>suppress_redundant_updates_trigger</>, 
-         which will prevent any update
-         that does not actually change the data in the row from taking place, in
-         contrast to the normal behaviour which always performs the update
-         regardless of whether or not the data has changed. (This normal behaviour
-         makes updates run faster, since no checking is required, and is also
-         useful in certain cases.)
+      function, <function>suppress_redundant_updates_trigger</>, 
+      which will prevent any update
+      that does not actually change the data in the row from taking place, in
+      contrast to the normal behaviour which always performs the update
+      regardless of whether or not the data has changed. (This normal behaviour
+      makes updates run faster, since no checking is required, and is also
+      useful in certain cases.)
     </para>
 
-       <para>
-         Ideally, you should normally avoid running updates that don't actually
-         change the data in the record. Redundant updates can cost considerable
-         unnecessary time, especially if there are lots of indexes to alter,
-         and space in dead rows that will eventually have to be vacuumed.
-         However, detecting such situations in client code is not
-         always easy, or even possible, and writing expressions to detect
-         them can be error-prone. An alternative is to use 
-         <function>suppress_redundant_updates_trigger</>, which will skip
-         updates that don't change the data. You should use this with care,
-         however. The trigger takes a small but non-trivial time for each record, 
-         so if most of the records affected by an update are actually changed,
-         use of this trigger will actually make the update run slower.
+    <para>
+      Ideally, you should normally avoid running updates that don't actually
+      change the data in the record. Redundant updates can cost considerable
+      unnecessary time, especially if there are lots of indexes to alter,
+      and space in dead rows that will eventually have to be vacuumed.
+      However, detecting such situations in client code is not
+      always easy, or even possible, and writing expressions to detect
+      them can be error-prone. An alternative is to use 
+      <function>suppress_redundant_updates_trigger</>, which will skip
+      updates that don't change the data. You should use this with care,
+      however. The trigger takes a small but non-trivial time for each record, 
+      so if most of the records affected by an update are actually changed,
+      use of this trigger will actually make the update run slower.
     </para>
 
     <para>
       The <function>suppress_redundant_updates_trigger</> function can be 
-         added to a table like this:
+      added to a table like this:
 <programlisting>
 CREATE TRIGGER z_min_update 
 BEFORE UPDATE ON tablename
 FOR EACH ROW EXECUTE PROCEDURE suppress_redundant_updates_trigger();
 </programlisting>
       In most cases, you would want to fire this trigger last for each row.
-         Bearing in mind that triggers fire in name order, you would then
-         choose a trigger name that comes after the name of any other trigger
+      Bearing in mind that triggers fire in name order, you would then
+      choose a trigger name that comes after the name of any other trigger
       you might have on the table.
     </para>
-       <para>
+    <para>
        For more information about creating triggers, see
-           <xref linkend="SQL-CREATETRIGGER">.
+        <xref linkend="SQL-CREATETRIGGER">.
     </para>
   </sect1>
 </chapter>