Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread
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
Date: 2020-11-06T20:25:39Z
Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Revert "Accept relations of any kind in LOCK TABLE".

  2. Revert "pg_dump: Lock all relations, not just plain tables".

  3. Doc: undo mistaken adjustment to LOCK TABLE docs in back branches.

  4. Don't throw an error for LOCK TABLE on a self-referential view.

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