From 287ed68dd2a8f0be6f10f6bd373e4c9c3887b821 Mon Sep 17 00:00:00 2001
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 26 Mar 2007 01:41:57 +0000
Subject: [PATCH] Remove assertion that constraint_exclusion risks wrong
 answers if table constraints are changed; this is no longer true now that we
 have a plan invalidation mechanism.

---
 doc/src/sgml/config.sgml | 10 ++--------
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index fab7cc4b0d..07d1a879b3 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.117 2007/03/22 15:46:56 momjian Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.118 2007/03/26 01:41:57 tgl Exp $ -->
 
 <chapter Id="runtime-config">
   <title>Server Configuration</title>
@@ -2140,13 +2140,7 @@ SELECT * FROM parent WHERE key = 2400;
 
        <para>
         Currently, <varname>constraint_exclusion</> is disabled by
-        default because it risks incorrect results if query plans are
-        cached &mdash; if a table constraint is changed or dropped,
-        the previously generated plan might now be wrong, and there is
-        no built-in mechanism to force re-planning.  (This deficiency
-        will probably be addressed in a future
-        <productname>PostgreSQL</> release.)  Another reason for
-        keeping it off is that the constraint checks are relatively
+        default because the constraint checks are relatively
         expensive, and in many circumstances will yield no savings.
         It is recommended to turn this on only if you are actually
         using partitioned tables designed to take advantage of the