Horton

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

Andrew Bille <andrewbille@gmail.com>

View thread
From: Andrew Bille <andrewbille@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2020-11-06T16:42:33Z
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.

Thanks.

After removing views like this from my dump, produced from the modified
regression test results (with most of DROP's deleted), I did not find any
other problems

regards, Andrew Bille

On Fri, Nov 6, 2020 at 10:05 PM Tom Lane <tgl@sss.pgh.pa.us> 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.)
>
> 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
>