On Fri, Jun 21, 2024, at 05:25, Michael Paquier wrote: > Interesting idea. > > I am not really convinced that the regproc and regclass overloads are > really necessary, considering the fact that one of the goals > mentioned, as far as I understand, is to be able to get an idea of the > ACLs associated to an object with its dependencies in pg_depend and/or > pg_shdepend. Another one is to reduce the JOIN burden when querying > a set of them, like attribute ACLs.
Overloads moved to a second patch, which can be applied on top of the first one. I think they would be quite nice, but I could also live without them. > Perhaps the documentation should add one or two examples to show this > point? Good point, added. > > + tup = get_catalog_object_by_oid(rel, Anum_oid, objectId); > + if (!HeapTupleIsValid(tup)) > + elog(ERROR, "cache lookup failed for object %u of catalog > \"%s\"", > + objectId, RelationGetRelationName(rel)); > > get_catalog_object_by_oid() is handled differently here than in > functions line pg_identify_object(). Shouldn't we return NULL for > this case? That would be more useful when using this function with > one or more large scans. Right, I've changed the patch accordingly. On Fri, Jun 21, 2024, at 05:48, Isaac Morland wrote: > Those were just examples. I think for completeness there should be 5 > overloads: > > [input type] → [relation.aclattribute] > regproc/regprocedure → pg_proc.proacl > regtype → pg_type.typacl > regclass → pg_class.relacl > regnamespace → pg_namespace.nspacl > > I believe the remaining reg* types don't correspond to objects with > ACLs, and the remaining ACL fields are for objects which don't have a > corresponding reg* type. > > In general I believe the reg* types are underutilized. All over the > place I see examples where people write code to generate SQL statements > and they take schema and object name and then format with %I.%I when > all that is needed is a reg* value and then format it with a simple %s > (of course, need to make sure the SQL will execute with the same > search_path as when the SQL was generated, or generate with an empty > search_path). I've added regtype and regnamespace overloads to the second patch. On Fri, Jun 21, 2024, at 05:58, Isaac Morland wrote: > On Thu, 20 Jun 2024 at 23:44, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Doesn't that result in "cannot resolve ambiguous function call" >> failures? > > If you try to pass an oid directly, as a value of type oid, you should > get "function is not unique". But if you cast a string or numeric value > to the appropriate reg* type for the object you are using, it should > work fine. Yes, I can confirm that's the case, it works fine when casting a string to reg* type. /Joel
v4-0001-Add-pg_get_acl.patch
Description: Binary data
0002-Add-pg_get_acl-overloads.patch
Description: Binary data
