Re: pg_upgrade fails with non-standard ACL

On Thu, Jan 21, 2021 at 01:03:58AM +0300, Anastasia Lubennikova wrote:
> On 03.01.2021 14:29, Noah Misch wrote:
> >Overall, this patch predicts a subset of cases where pg_dump will emit a
> >failing GRANT or REVOKE that targets a pg_catalog object. Can you write a
> >code comment stating what it does and does not detect? I think it's okay to
> >not predict every failure, but let's record the intended coverage. Here are a
> >few examples I know; there may be more. The above query only finds GRANTs to
> >non-pinned roles. pg_dump dumps the following, but the above query doesn't
> >find them:
> >
> > REVOKE ALL ON FUNCTION pg_last_wal_replay_lsn FROM public;
> > GRANT EXECUTE ON FUNCTION pg_reload_conf() TO pg_signal_backend;

I see a new comment listing object types. Please also explain the lack of
preventing REVOKE failures (first example query above) and the limitation
around non-pinned roles (second example).

> >The above query should test refclassid.

Please do so.

> + /* Handle table column objects */
> + if (strstr(aclinfo->obj_type, "column") != NULL)
> + {
> + char *name_pos = strstr(aclinfo->obj_ident,
> + aclinfo->obj_name);

> + if (*name_pos == '\"')
> + name_pos--;

This solves the problem affecting a column named "a.b", but it fails for a
column named "pg_catalog" or "a""b". I recommend solving this by retrieving
all three elements of the pg_identify_object_as_address array, then quoting
each of them on the client side.