From: | "Joel Jacobson" <joel(at)compiler(dot)org> |
---|---|
To: | "Isaac Morland" <isaac(dot)morland(at)gmail(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Michael Paquier" <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add pg_get_acl() function get the ACL for a database object |
Date: | 2024-06-22 00:54:30 |
Message-ID: | 280e2479-30c7-4f94-b077-baff19af3546@app.fastmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)sss(dot)pgh(dot)pa(dot)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 | Content-Type | Size |
---|---|---|
v4-0001-Add-pg_get_acl.patch | application/octet-stream | 6.6 KB |
0002-Add-pg_get_acl-overloads.patch | application/octet-stream | 15.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andy Fan | 2024-06-22 03:10:41 | Re: Shared detoast Datum proposal |
Previous Message | Alena Rybakina | 2024-06-21 22:52:02 | Re: POC, WIP: OR-clause support for indexes |