Re: BUG #16703: pg-dump fails to process recursive view definition

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16703: pg-dump fails to process recursive view definition
Date: 2020-11-05 16:20:29
Message-ID: 1477409.1604593229@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Further news: I thought to myself "let's leave a self-referential view
behind in the final regression test state, so we can actually exercise
pg_dump/pg_upgrade with one". It turns out that that's not gonna work,
at least not right away. pg_dump dumps the view all right, but it dumps

CREATE VIEW "public"."self_referential_view" AS
SELECT "self_referential_view"."key",
"self_referential_view"."data"
FROM "public"."self_referential_view";

which of course fails to load, complaining "relation
"public.self_referential_view" does not exist".

I'm not particularly desperate to do anything about that. It's important
that pg_dump not fail on such a view, so you don't have a risk that your
backups didn't work at all. But if you have to do some finagling to
restore it, that's less critical. Also, this has been the situation all
along and there have been no complaints.

One could imagine getting pg_dump to handle this by treating the
self-reference as a circular reference and then doing what it does
to break reference loops with views. I experimented briefly with
that, but it's a bigger can of worms than it seems; pg_dump_sort.c
does not seem to have quite enough info to tell whether references
are explicit self-references or not.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message David G. Johnston 2020-11-05 17:43:45 Re: Wrong result for comparing ROW(...) with IS NOT NULL
Previous Message Tom Lane 2020-11-05 15:41:48 Re: BUG #16703: pg-dump fails to process recursive view definition