aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistvacuum.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2017-07-24 15:16:31 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2017-07-24 15:16:31 -0400
commitf0f255a34bedeaa38f01685732bcfd50ed2d21f8 (patch)
tree157d827bf4b0f4d87ec079693020c0b82cf9c304 /src/backend/access/gist/gistvacuum.c
parent0328bd1ef3c991d4764d8437d9a407033d4d4a5c (diff)
downloadpostgresql-f0f255a34bedeaa38f01685732bcfd50ed2d21f8.tar.gz
postgresql-f0f255a34bedeaa38f01685732bcfd50ed2d21f8.zip
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
Diffstat (limited to 'src/backend/access/gist/gistvacuum.c')
0 files changed, 0 insertions, 0 deletions