Sigh, I managed to break the no-links-in-plain-text-docs rule too...
authorTom Lane
Sat, 19 Dec 2009 05:37:01 +0000 (05:37 +0000)
committerTom Lane
Sat, 19 Dec 2009 05:37:01 +0000 (05:37 +0000)
doc/src/sgml/release-8.5.sgml

index 668c2adc2fbc7111b2ac98bfdd3f958afb3353e4..12f9eff68ca5040c288f1d536298d7768828f142 100644 (file)
@@ -1,4 +1,4 @@
-
+
 
 
   Release 8.5alpha3
           meant, sometimes resulting in surprising behavior.  Now, PL/pgSQL
           can assume the variable is meant, or assume the table column is
           meant, or throw an error in ambiguous cases.  For safety the default
-          is to throw error.  To configure this see <xref
-          linkend="plpgsql-var-subst">.
+          is to throw error.  To configure this see <link
+          linkend="plpgsql-var-subst">the PL/pgSQL documentation.
         
         
          Error reporting is much nicer: it no longer shows edited
         
          Note that this change affects the set of keywords that are
           reserved in PL/pgSQL (i.e., cannot be the name of a PL/pgSQL
-          variable).  Now, all keywords shown as reserved in <xref
-          linkend="sql-keywords-appendix"> are reserved for PL/pgSQL purposes
-          as well.  However, many PL/pgSQL-only keywords that were formerly
-          treated as reserved no longer are.  As in regular SQL, you can
-          double-quote a variable's name if you want to use a name that
-          conflicts with a reserved keyword.
+          variable).  Now, all keywords shown as reserved in <link
+          linkend="sql-keywords-appendix">Appendix C are reserved for
+          PL/pgSQL purposes as well.  However, many PL/pgSQL-only keywords
+          that were formerly treated as reserved no longer are.  As in regular
+          SQL, you can double-quote a variable's name if you want to use a
+          name that conflicts with a reserved keyword.