On Wed, Nov 27, 2019 at 11:35:14AM +0900, Artur Zakirov wrote: > I've started to implement new backend function similar to > pg_describe_object() and tried to make new version of the patch. But I'm > wondering now if it is possible to backpatch new functions to older > Postgres releases? pg_upgrade will require a presence of this function on an > older source cluster.
New functions cannot be backpatched because it would require a catalog bump. > Other approach is similar to Anastasia's patch, which is scanning pg_proc, > pg_class, pg_attribute and others to get modified ACL's and compare it with > initial ACL from pg_init_privs. Next step is to find objects which names or > signatures were changed using pg_describe_object() and scanning pg_depend of > new cluster Yeah, the actual take is if we want to make the frontend code more complicated with a large set of SQL queries to check that each object ACL is modified, which adds an additional maintenance cost in pg_upgrade. Or if we want to keep the frontend simple and have more backend facility to ease cross-catalog lookups for ACLs. Perhaps we could also live with just checking after the ACLs of functions in the short term and perhaps it covers most of the cases users would care about.. That's tricky to conclude about and I am not sure which path is better in the long-term, but at least it's worth discussing all possible candidates IMO so as we make sure to not miss anything. > (there is a problem here though: there are no entries for > relations columns). When it comes to column ACLs, pg_shdepend stores a dependency between the column's relation and the role. -- Michael
signature.asc
Description: PGP signature