Fix yet another corner case in dumping rules/views with USING clauses.
authorTom Lane <tgl@sss.pgh.pa.us>
Fri, 2 May 2014 00:22:39 +0000 (20:22 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 2 May 2014 00:22:39 +0000 (20:22 -0400)
commite31193d495f668b2e2e98db290f36af83b6c70e8
tree4ff2c9cffac41673ed7fca0ba37e1094cc466188
parentb72e90bc3117a03f8964a2a5e74f92ecef0328af
Fix yet another corner case in dumping rules/views with USING clauses.

ruleutils.c tries to cope with additions/deletions/renamings of columns in
tables referenced by views, by means of adding machine-generated aliases to
the printed form of a view when needed to preserve the original semantics.
A recent blog post by Marko Tiikkaja pointed out a case I'd missed though:
if one input of a join with USING is itself a join, there is nothing to
stop the user from adding a column of the same name as the USING column to
whichever side of the sub-join didn't provide the USING column.  And then
there'll be an error when the view is re-parsed, since now the sub-join
exposes two columns matching the USING specification.  We were catching a
lot of related cases, but not this one, so add some logic to cope with it.

Back-patch to 9.3, which is the first release that makes any serious
attempt to cope with such cases (cf commit 2ffa740be and follow-ons).
src/backend/utils/adt/ruleutils.c
src/test/regress/expected/create_view.out
src/test/regress/sql/create_view.sql