Re: BUG #6699: pg_restore with -j -- doesn't restore view that groups by primary key

I wrote:
> Hmm ... check_functional_grouping does add the PK's OID to the query's
> constraintDeps list.  Apparently we're losing that dependency knowledge
> somewhere between the parser and pg_dump?

I looked into this a bit.  The dependency does exist in pg_depend, but
it is shown as a dependency from the view's _RETURN rule to the
constraint, not as a dependency of the view itself.  Using the
simplified example

create table t1 (f1 int primary key, f2 text);
create view v1 as select * from t1 group by f1;

what you get from "pg_dump -Fc | pg_restore -l -v" is

; Selected TOC Entries:
;
1923; 0 0 ENCODING - ENCODING
1924; 0 0 STDSTRINGS - STDSTRINGS
1925; 1262 41967 DATABASE - refbug postgres
5; 2615 2200 SCHEMA - public postgres
1926; 0 0 COMMENT - SCHEMA public postgres
;       depends on: 5
1927; 0 0 ACL - public postgres
;       depends on: 5
170; 3079 11727 EXTENSION - plpgsql
1928; 0 0 COMMENT - EXTENSION plpgsql
;       depends on: 170
168; 1259 41968 TABLE public t1 postgres
;       depends on: 5
1921; 2606 41975 CONSTRAINT public t1_pkey postgres
;       depends on: 168 168
169; 1259 41976 VIEW public v1 postgres
;       depends on: 1919 5
1922; 0 41968 TABLE DATA public t1 postgres
;       depends on: 168

So the view is shown as depending on "object 1919", which is nowhere to
be seen, because it is the _RETURN rule which did not get dumped
separately.  There is therefore no way at all for pg_restore to know
that the view has to be restored after the constraint.  (pg_dump does
know that, since it was working with full dependency info, which is why
the constraint comes first in the dump order.  But the info isn't
exposed where pg_restore can see it.)

Clearly, this is a bug in the way pg_dump emits dependency info.
It never mattered before, but parallel pg_restore really needs accurate
dependencies.

We could possibly hack something for the special case of rules, but
I don't think this would be the last time we hear about this type of
issue.  I'm inclined to think that the best solution would be to add
generic logic to pg_dump that "looks through" any dependency references
to objects that are not going to be dumped, and replaces them with the
IDs of any objects they depend on that are going to be dumped.

            regards, tom lane