Re: pg_dumpall -r -c try to drop user postgres
От | Pavel Stehule |
---|---|
Тема | Re: pg_dumpall -r -c try to drop user postgres |
Дата | |
Msg-id | CAFj8pRBZV7HFk-UEXTkKE1AAoqZZ1B0BmNGmPRbdAjuCwu8-bw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_dumpall -r -c try to drop user postgres (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: pg_dumpall -r -c try to drop user postgres
|
Список | pgsql-hackers |
2017-12-03 23:48 GMT+01:00 Michael Paquier <michael.paquier@gmail.com>:
On Sun, Dec 3, 2017 at 3:21 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> I am not sure if user postgres should be removed, so it is probably bug
>
> pg_dumpall -r -c | grep postgres
>
> DROP ROLE postgres;
> CREATE ROLE postgres;
You are looking for this bit of code:
/*
* If asked to --clean, do that first. We can avoid detailed
* dependency analysis because databases never depend
on each other,
* and tablespaces never depend on each other. Roles could have
* grants to each other, but DROP ROLE will clean
those up silently.
*/
if (output_clean)
{
if (!globals_only && !roles_only && !tablespaces_only)
dropDBs(conn);
if (!roles_only && !no_tablespaces)
dropTablespaces(conn);
if (!tablespaces_only)
dropRoles(conn);
}
Could you clarify what you think is wrong here?
I am not sure, if issue is in this code. But I am sure, so DROP ROLE postgres is just nonsense
This command should to fail every time, and then should not be generated.
Regards
Pavel
--
Michael
В списке pgsql-hackers по дате отправления: