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