Fix yet another corner case in dumping rules/views with USING clauses.
Tom Lane <tgl@sss.pgh.pa.us>
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).
Files
| Path | Change | +/− |
|---|---|---|
| src/backend/utils/adt/ruleutils.c | modified | +38 −11 |
| src/test/regress/expected/create_view.out | modified | +34 −0 |
| src/test/regress/sql/create_view.sql | modified | +18 −0 |