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
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 |