Re: schema-only pg_dump inconsistently dumps some view definitions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Keith Fiske <keith(at)omniti(dot)com>
Cc: "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: schema-only pg_dump inconsistently dumps some view definitions
Date: 2015-11-30 23:09:25
Message-ID: 26994.1448924965@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Keith Fiske <keith(at)omniti(dot)com> writes:
> Ran into a weird issue with pg_dump outputting an odd definition for a
> view. First, the view definition
> https://gist.github.com/keithf4/24298f7327b4a27054fd
> If a pg_dump -s or pg_dumpall -s for the entire database is used, it
> outputs the view definition as a table with an ALTER TABLE statement
> related to logical replication followed by the "_RETURN" rule later on in
> the dump file.

pg_dump does that when it's trying to break a circular dependency;
that is, there is something referenced in the view definition that
cannot be defined before the view exists. The typical thing I've
seen is a view defined in terms of a function that takes or returns
the view's named rowtype.

It's not real clear why it's doing it here, though if you can submit
a self-contained test case we could take a look. I suspect though
that the answer will be "not a bug".

There's been some speculation about revising pg_dump so that what
it puts out in such cases involves a dummy view definition followed
later by CREATE OR REPLACE VIEW. No one's gotten around to writing
a patch for that though, and I rather imagine that it would break
unsuspecting tools anyway :-(

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruce Momjian 2015-12-01 01:55:53 Re: BUG #13746: SQL Query Window stopped working
Previous Message Keith Fiske 2015-11-30 21:42:53 Re: schema-only pg_dump inconsistently dumps some view definitions