Back-branch release notes up for review

On Sat, Aug 26, 2017 at 03:31:12PM -0400, Tom Lane wrote:

+    <listitem>
+<!--
+Author: Peter Eisentraut <peter_e@gmx.net>
+Branch: master [0659465ca] 2017-08-15 19:27:22 -0400
+Branch: REL_10_STABLE [3ea58216d] 2017-08-15 19:30:35 -0400
+Branch: REL9_6_STABLE [dce90c7c8] 2017-08-15 19:31:06 -0400
+Branch: REL9_5_STABLE [dbeefe64f] 2017-08-15 19:32:00 -0400
+Branch: REL9_4_STABLE [52427015a] 2017-08-15 19:32:41 -0400
+Branch: REL9_3_STABLE [9f0f4efc2] 2017-08-15 19:32:52 -0400
+Branch: REL9_2_STABLE [98e6784aa] 2017-08-15 19:33:04 -0400
+-->
+     <para>
+      Show foreign tables
+      in <structname>information_schema</>.<structname>table_privileges</>
+      view (Peter Eisentraut)
+     </para>
+
+     <para>
+      All other relevant <structname>information_schema</> views include
+      foreign tables, but this one ignored them.
+     </para>
+
+     <para>
+      Since this view definition is installed by <application>initdb</>,
+      merely upgrading will not fix the problem.  If you need to fix this
+      in an existing installation, you can, as a superuser, do this
+      in <application>psql</>:
+<programlisting>
+BEGIN;
+DROP SCHEMA information_schema CASCADE;
+\i <replaceable>SHAREDIR</>/information_schema.sql
+COMMIT;
+</programlisting>
+      (Run <literal>pg_config --sharedir</> if you're uncertain
+      where <replaceable>SHAREDIR</> is.)  This must be repeated in each
+      database to be fixed.
+     </para>
+    </listitem>

"DROP SCHEMA information_schema CASCADE;" will drop objects outside
information_schema that depend on objects inside information_schema. For
example, this will drop user-defined views if the view query refers to
information_schema. That's improper in a release-noted update procedure.
This could instead offer a CREATE OR REPLACE VIEW or just hand-wave about the
repaired definition being available in information_schema.sql.

I regret not reading this before today.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Thu, Aug 31, 2017 at 02:53:45AM +0000, Noah Misch wrote:

On Sat, Aug 26, 2017 at 03:31:12PM -0400, Tom Lane wrote:

+    <listitem>
+<!--
+Author: Peter Eisentraut <peter_e@gmx.net>
+Branch: master [0659465ca] 2017-08-15 19:27:22 -0400
+Branch: REL_10_STABLE [3ea58216d] 2017-08-15 19:30:35 -0400
+Branch: REL9_6_STABLE [dce90c7c8] 2017-08-15 19:31:06 -0400
+Branch: REL9_5_STABLE [dbeefe64f] 2017-08-15 19:32:00 -0400
+Branch: REL9_4_STABLE [52427015a] 2017-08-15 19:32:41 -0400
+Branch: REL9_3_STABLE [9f0f4efc2] 2017-08-15 19:32:52 -0400
+Branch: REL9_2_STABLE [98e6784aa] 2017-08-15 19:33:04 -0400
+-->
+     <para>
+      Show foreign tables
+      in <structname>information_schema</>.<structname>table_privileges</>
+      view (Peter Eisentraut)
+     </para>
+
+     <para>
+      All other relevant <structname>information_schema</> views include
+      foreign tables, but this one ignored them.
+     </para>
+
+     <para>
+      Since this view definition is installed by <application>initdb</>,
+      merely upgrading will not fix the problem.  If you need to fix this
+      in an existing installation, you can, as a superuser, do this
+      in <application>psql</>:
+<programlisting>
+BEGIN;
+DROP SCHEMA information_schema CASCADE;
+\i <replaceable>SHAREDIR</>/information_schema.sql
+COMMIT;
+</programlisting>
+      (Run <literal>pg_config --sharedir</> if you're uncertain
+      where <replaceable>SHAREDIR</> is.)  This must be repeated in each
+      database to be fixed.
+     </para>
+    </listitem>

"DROP SCHEMA information_schema CASCADE;" will drop objects outside
information_schema that depend on objects inside information_schema. For
example, this will drop user-defined views if the view query refers to
information_schema. That's improper in a release-noted update procedure.
This could instead offer a CREATE OR REPLACE VIEW or just hand-wave about the
repaired definition being available in information_schema.sql.

I lean toward the former, attached. Conveniently, every released branch has
the same definition for this view.