Fix dumping of a materialized view that depends on a table's primary key.
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 29 Mar 2014 21:34:00 +0000 (17:34 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 29 Mar 2014 21:34:00 +0000 (17:34 -0400)
commit62215de2925705bc607635e45ff800364456b1a1
tree04b546f5205fbb7842a32fda9e174492aec9fe34
parent8f5578d0f9681ef81bc71a3762a191d66a29c8b1
Fix dumping of a materialized view that depends on a table's primary key.

It is possible for a view or materialized view to depend on a table's
primary key, if the view query relies on functional dependency to
abbreviate a GROUP BY list.  This is problematic for pg_dump since we
ordinarily want to dump view definitions in the pre-data section but
indexes in post-data.  pg_dump knows how to deal with this situation for
regular views, by breaking the view's ON SELECT rule apart from the view
proper.  But it had not been taught what to do about materialized views,
and in fact mistakenly dumped them as regular views in such cases, as
seen in bug #9616 from Jesse Denardo.

If we had CREATE OR REPLACE MATERIALIZED VIEW, we could fix this in a
manner analogous to what's done for regular views; but we don't yet,
and we'd not back-patch such a thing into 9.3 anyway.  As a hopefully-
temporary workaround, break the circularity by postponing the matview
into post-data altogether when this case occurs.
src/bin/pg_dump/pg_dump.c
src/bin/pg_dump/pg_dump.h
src/bin/pg_dump/pg_dump_sort.c