Re: DROP OWNED BY fails to clean out pg_init_privs grants

Hello!

IIUC the regression test test_pg_dump [1] fails, see the attached 
regression.diffs:

diff -U3 
/Users/test/Work/postgrespro/src/test/modules/test_pg_dump/expected/test_pg_dump.out 
/Users/test/Work/postgrespro/build/testrun/test_pg_dump-running/regress/results/test_pg_dump.out
--- 
/Users/test/Work/postgrespro/src/test/modules/test_pg_dump/expected/test_pg_dump.out	2024-09-12 
15:02:26.345434331 +0700
+++ 
/Users/test/Work/postgrespro/build/testrun/test_pg_dump-running/regress/results/test_pg_dump.out	2024-09-12 
15:42:09.341520173 +0700

[1] 
https://github.com/postgres/postgres/blob/master/src/test/modules/test_pg_dump/sql/test_pg_dump.sql

On 2024-09-18 07:31, Tom Lane wrote:
> =?UTF-8?B?0JXQs9C+0YAg0KfQuNC90LTRj9GB0LrQuNC9?= <kyzevan23@mail.ru> 
> writes:
>> This query does not expect that test database may already contain some 
>> information about custom user that ran test_pg_dump-running.
> 
> I'm perfectly content to reject this as being an abuse of the test
> case.  Our TAP tests are built on the assumption that they use
> databases created within the test case.  Apparently, you've found a
> way to use the meson test infrastructure to execute a TAP test in
> the equivalent of "make installcheck" rather than "make check" mode.
> I am unwilling to buy into the proposition that our TAP tests should
> be proof against doing that after making arbitrary changes to the
> database's initial state.  If anything, the fact that this is possible
> is a bug in our meson scripts.
> 
> 			regards, tom lane

-- 
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company