|From:||Michael Paquier <michael(at)paquier(dot)xyz>|
|To:||Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>|
|Cc:||Stephen Frost <sfrost(at)snowman(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org|
|Subject:||Re: pg_upgrade fails with non-standard ACL|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Mon, Oct 28, 2019 at 05:40:44PM +0300, Anastasia Lubennikova wrote:
> I added more comments and updated the error message.
> Please, feel free to fix them, if you have any suggestions.
I have begun looking at this one.
+ /* REVOKE command must be executed in corresponding database */
+ if (*new_db)
+ fprintf(*script, _("\\c %s \n"), olddbinfo->db_name);
+ *new_db = false;
This will fail if the database to use includes a space? And it seems
to me that log_incompatible_procedure() does not quote things
+ * from initial privilleges. Only check privileges set by initdb.
I think that there is little point to keep get_catalog_procedures()
and check_catalog_procedures() separated. Why not just using a single
Wouldn't it be more simple to just use a cast as
pg_proc.oid::regprocedure in the queries?
Let's also put some effort in the formatting of the SQL queries here:
- Schema-qualification with pg_catalog.
- Format of the clauses could be better (for examples two-space
indentation for clauses, etc.)
I think that we should keep the core part of the fix more simple by
just warning about missing function signatures in the target cluster
when pg_upgrade --check is used. So I think that it would be better
for now to get to a point where we can warn about the function
signatures involved in a given database, without the generation of the
script with those REVOKE queries. Or would folks prefer keep that in
the first version? My take would be to handle both separately, and to
warn about everything so as there is no need to do pg_upgrade --check
more than once.
I may be missing something, but it seems to me that there is no need
to attach proc_arr to DbInfo or have traces of it in pg_upgrade.h as
long as you keep the checks of function signatures local to the single
entry point I am mentioning above.
|Next Message||Michael Paquier||2019-11-08 09:05:07||Re: [PATCH][DOC] Fix for PREPARE TRANSACTION doc and postgres_fdw message.|
|Previous Message||Kuntal Ghosh||2019-11-08 08:52:32||Re: Ordering of header file inclusion|