Re: pg_upgrade --check doesn't check pg_pltemplate modifications

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tomas Barton <barton(dot)tomas(at)gmail(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: pg_upgrade --check doesn't check pg_pltemplate modifications
Date: 2022-01-16 16:43:14
Message-ID: 3704260.1642351394@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Tomas Barton <barton(dot)tomas(at)gmail(dot)com> writes:
> Any non-default GRANT/REVOKE like these:

> REVOKE SELECT ON TABLE "pg_catalog"."pg_pltemplate" FROM PUBLIC;
> GRANT SELECT ON TABLE "pg_catalog"."pg_pltemplate" TO "reader";

Uh ... why would you do that? It seems only academically
different from randomly deleting some catalog entries.

> would break the upgrade process, even though the pg_upgrade --check says:
> *Clusters are compatible*

pg_upgrade has never promised to detect every possible problem.
Considering that pg_pltemplate is gone entirely in v13 and up,
I doubt we're going to want to invest a lot of effort here.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2022-01-16 21:00:44 Re: BUG #17363: 14 regression: "could not identify a hash function for type record" in a nested record in sublink
Previous Message Mario Emmenlauer 2022-01-16 15:30:13 Re: BUG #17365: Error: redefinition of 'stat' in win32_port.h when including postgres.h