From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Bille <andrewbille@gmail.com>
cc: Alvaro Herrera <alvherre@2ndquadrant.com>, exclusion@gmail.com,
        pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16703: pg-dump fails to process recursive view definition
In-reply-to: <1571034.1604675132@sss.pgh.pa.us>
References: <16703-e348f58aab3cf6cc@postgresql.org>
 <1438431.1604588428@sss.pgh.pa.us> <1473888.1604590908@sss.pgh.pa.us>
 <1477409.1604593229@sss.pgh.pa.us>
 <CAJnzarze97y5Q4NTxpc5zXuDNM-82g+0c1q_9HwD5DuqcBm4mQ@mail.gmail.com>
 <1571034.1604675132@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Fri, 06 Nov 2020 10:05:32 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1624927.1604694339.1@sss.pgh.pa.us>
Date: Fri, 06 Nov 2020 15:25:39 -0500
Message-ID: <1624928.1604694339@sss.pgh.pa.us>
Precedence: bulk

I wrote:
> Andrew Bille <andrewbille@gmail.com> writes:
>> pg_dump is also fails to process the view created by the following script
>> (excerpt from privileges.sql):

>> CREATE USER user1;
>> CREATE TABLE test (col1 varchar(10), col2 boolean);
>> SET SESSION AUTHORIZATION user1;
>> CREATE VIEW testv AS SELECT * FROM test;

> Hm, yeah, so more to do here.  (Sure glad we found these issues before
> next week's releases, not after.)

After some off-list discussion with Alvaro, we're thinking the best way
forward is to revert the pg_dump and LOCK TABLE changes for now, and
try again after next week's releases.  My proposal about

> (2) Make LOCK TABLE ONLY on a view not recurse to the view's dependencies.

seems like it needs wider discussion, and there's not really time to
get that done before the wrap.  Having found these two bugs in the patch
set doesn't inspire confidence that there aren't others, too.

			regards, tom lane