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: 
 <CAJnzarze97y5Q4NTxpc5zXuDNM-82g+0c1q_9HwD5DuqcBm4mQ@mail.gmail.com>
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>
Comments: In-reply-to Andrew Bille <andrewbille@gmail.com>
	message dated "Fri, 06 Nov 2020 21:28:09 +0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1571033.1604675132.1@sss.pgh.pa.us>
Date: Fri, 06 Nov 2020 10:05:32 -0500
Message-ID: <1571034.1604675132@sss.pgh.pa.us>
Precedence: bulk

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

I propose that what we'd better do is

(1) Make pg_dump use LOCK TABLE ONLY, not LOCK TABLE.

(2) Make LOCK TABLE ONLY on a view not recurse to the view's dependencies.
It's quite unclear to me why it didn't work that way all along.

			regards, tom lane