diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2014-05-01 20:22:37 -0400 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2014-05-01 20:22:37 -0400 |
| commit | 91e16b980612d80de1017e97e9f206239afb9026 (patch) | |
| tree | 8966bf3bf74707fbae03afd4c952dfcf8d61ffc4 /src/test/regress/expected/create_view.out | |
| parent | 4c8aa8b5aea1e032f569222d4b6c1019e84622dc (diff) | |
| download | postgresql-91e16b980612d80de1017e97e9f206239afb9026.tar.gz | |
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).
Diffstat (limited to 'src/test/regress/expected/create_view.out')
| -rw-r--r-- | src/test/regress/expected/create_view.out | 34 |
1 files changed, 34 insertions, 0 deletions
diff --git a/src/test/regress/expected/create_view.out b/src/test/regress/expected/create_view.out index 1b95e90e02..06b203793a 100644 --- a/src/test/regress/expected/create_view.out +++ b/src/test/regress/expected/create_view.out @@ -1298,6 +1298,40 @@ select pg_get_viewdef('vv5', true); JOIN tt10 USING (x); (1 row) +-- +-- Another corner case is that we might add a column to a table below a +-- JOIN USING, and thereby make the USING column name ambiguous +-- +create table tt11 (x int, y int); +create table tt12 (x int, z int); +create table tt13 (z int, q int); +create view vv6 as select x,y,z,q from + (tt11 join tt12 using(x)) join tt13 using(z); +select pg_get_viewdef('vv6', true); + pg_get_viewdef +--------------------------- + SELECT tt11.x, + + tt11.y, + + tt12.z, + + tt13.q + + FROM tt11 + + JOIN tt12 USING (x) + + JOIN tt13 USING (z); +(1 row) + +alter table tt11 add column z int; +select pg_get_viewdef('vv6', true); + pg_get_viewdef +------------------------------ + SELECT tt11.x, + + tt11.y, + + tt12.z, + + tt13.q + + FROM tt11 tt11(x, y, z_1)+ + JOIN tt12 USING (x) + + JOIN tt13 USING (z); +(1 row) + -- clean up all the random objects we made above set client_min_messages = warning; DROP SCHEMA temp_view_test CASCADE; |
