Re: ACL dump ordering broken as well for tablespaces

From: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, "kommi(dot)haribabu(at)gmail(dot)com" <kommi(dot)haribabu(at)gmail(dot)com>
Subject: Re: ACL dump ordering broken as well for tablespaces
Date: 2019-05-22 18:35:31
Message-ID: A15B979F-1A48-4B8C-AFDF-47089BDE088C@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 5/22/19, 12:16 AM, "Michael Paquier" <michael(at)paquier(dot)xyz> wrote:
> Attached is a patch to fix that, so as pg_dumpall does not complain
> when piling up GRANT commands using WITH GRANT OPTION. Are there any
> complains to apply that down to 9.6?

The patch looks good to me.

> As the problem is kind of different than the database case, I wanted
> to spawn anyway a new thread, but I got a bonus question: what would
> it take to support pg_init_privs for databases and tablespaces? If we
> could get that to work, then all the ACL-related queries built for all
> objects could make use of buildACLQueries(), which would avoid extra
> diffs in the dump code for dbs and tbspaces.

A bit of digging led me to the commit that removed databases and
tablespaces from pg_init_privs [0] and to a related thread [1]. IIUC
the problem is that using pg_init_privs for databases is complicated
by the ability to drop and recreate the template databases.

Nathan

[0] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=47f5bb9f539a7fff089724b1cbacc31613031895
[1] https://www.postgresql.org/message-id/9f25cb66-df67-8d81-ed6a-d18692a03410%402ndquadrant.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-05-22 18:39:54 Re: pg_dump throwing "column number -1 is out of range 0..36" on HEAD
Previous Message Donald Dong 2019-05-22 18:35:07 Re: Why could GEQO produce plans with lower costs than the standard_join_search?