pgsql: Ensure that pg_get_ruledef()'s output matches pg_get_viewdef()'s

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Ensure that pg_get_ruledef()'s output matches pg_get_viewdef()'s
Date: 2017-07-24 19:17:05
Message-ID: E1dZiqn-0007fs-14@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Ensure that pg_get_ruledef()'s output matches pg_get_viewdef()'s.

Various cases involving renaming of view columns are handled by having
make_viewdef pass down the view's current relation tupledesc to
get_query_def, which then takes care to use the column names from the
tupledesc for the output column names of the SELECT. For some reason
though, we'd missed teaching make_ruledef to do similarly when it is
printing an ON SELECT rule, even though this is exactly the same case.
The results from pg_get_ruledef would then be different and arguably wrong.
In particular, this breaks pre-v10 versions of pg_dump, which in some
situations would define views by means of emitting a CREATE RULE ... ON
SELECT command. Third-party tools might not be happy either.

In passing, clean up some crufty code in make_viewdef; we'd apparently
modernized the equivalent code in make_ruledef somewhere along the way,
and missed this copy.

Per report from Gilles Darold. Back-patch to all supported versions.

Discussion: https://postgr.es/m/ec05659a-40ff-4510-fc45-ca9d965d0838@dalibo.com

Branch
------
REL9_4_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/f0f255a34bedeaa38f01685732bcfd50ed2d21f8

Modified Files
--------------
src/backend/utils/adt/ruleutils.c | 25 ++++++++++++++++++++-----
src/test/regress/expected/create_view.out | 29 +++++++++++++++++++++++++++++
src/test/regress/sql/create_view.sql | 11 +++++++++++
3 files changed, 60 insertions(+), 5 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Robert Haas 2017-07-24 20:25:41 pgsql: When WCOs are present, disable direct foreign table modification
Previous Message Tom Lane 2017-07-24 15:23:36 pgsql: Be more consistent about errors for opfamily member lookup failu