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.
