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 @@
-
+
 
  
   Functions and Operators
@@ -12855,46 +12855,46 @@ SELECT (pg_stat_file('filename')).modification;
 
    
       Currently PostgreSQL provides one built in trigger
-     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, 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.)
     
 
-   
-     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 
-     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.
+    
+      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 
+      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.
     
 
     
       The suppress_redundant_updates_trigger function can be 
-     added to a table like this:
+      added to a table like this:
 
 CREATE TRIGGER z_min_update 
 BEFORE UPDATE ON tablename
 FOR EACH ROW EXECUTE PROCEDURE suppress_redundant_updates_trigger();
 
       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.
     
-   
+    
        For more information about creating triggers, see
-       .
+        .