Log Message:
-----------
Added a conspicuous caution to docs that TABLE ADD KEY is not recommended

Tags:
----
REL_1_1_STABLE

Modified Files:
--------------
    slony1-engine/doc/adminguide:
        slonik_ref.sgml (r1.27.2.4 -> r1.27.2.5)

-------------- next part --------------
Index: slonik_ref.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/slonik_ref.sgml,v
retrieving revision 1.27.2.4
retrieving revision 1.27.2.5
diff -Ldoc/adminguide/slonik_ref.sgml -Ldoc/adminguide/slonik_ref.sgml -u -w -r1.27.2.4 -r1.27.2.5
--- doc/adminguide/slonik_ref.sgml
+++ doc/adminguide/slonik_ref.sgml
@@ -983,6 +983,21 @@
     we can't see there being terribly much interest in replicating
     tables that contain no application data.</para> </note>
     
+    <caution><para> <command>TABLE ADD KEY</command> <emphasis>should
+    not be used</emphasis> if you can possibly avoid it.  It is
+    emphatically <emphasis>not</emphasis> a <link
+    linkend="bestpractices"> Best Practice.</link> </para>
+
+    <para> The absence of a proper primary key should be a big red
+    flag that the database schema is <emphasis>broken.</emphasis> The
+    <emphasis>right</emphasis> way to repair this is to introduce a
+    proper primary key, not to have &slony1; <quote>fake</quote> one
+    up.</para> 
+
+    <para>It is <emphasis>not</emphasis> supported in <link
+    linkend="logshipping"> log shipping </link>, and will not
+    be.</para> </caution>
+    
     <para> This uses &funtableaddkey;. </para>
    </refsect1>
    <refsect1><title>Example</title>