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
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 |