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

Attachment: v4-0001-Add-pg_get_acl.patch
Description: Binary data

Attachment: 0002-Add-pg_get_acl-overloads.patch
Description: Binary data

Reply via email to