| 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: | Whole Thread | Raw Message | 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 |