From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Bille <andrewbille@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: exclusion@gmail.com
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16703: pg-dump fails to process recursive view definition
Date: Fri, 06 Nov 2020 10:05:32 -0500
Message-ID: <1571034.1604675132@sss.pgh.pa.us> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, andrewbille@gmail.com, 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>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox