Using aclitem[] at application layer

Started by A.M.over 15 years ago2 messagesgeneral
Jump to latest
#1A.M.
agentm@themactionfaction.com

Hello,

In an attempt to implement ACLs at the application layer (for resources stored outside of the database), I am evaluating using aclitem[] as a column type. All the functions I would need seem to be in place: aclcontains, aclexplode, aclinsert, aclitemeq, aclitemin, aclitemout, aclremove, but they are conspicuously missing from the documentation (http://www.mail-archive.com/pgsql-patches@postgresql.org/msg03400.html), so I wonder if there are any caveats or hurdles which would make me consider writing my own type.

From a cursory examination, it looks like the limitations would be:

1) roles must refer to postgresql roles (that's fine for my case)

2) permission options are hardcoded to "arwdDxtXUCTc" (not so great)

Are there any other problems I would encounter?

Cheers,
M

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: A.M. (#1)
Re: Using aclitem[] at application layer

"A.M." <agentm@themactionfaction.com> writes:

In an attempt to implement ACLs at the application layer (for resources stored outside of the database), I am evaluating using aclitem[] as a column type. All the functions I would need seem to be in place: aclcontains, aclexplode, aclinsert, aclitemeq, aclitemin, aclitemout, aclremove, but they are conspicuously missing from the documentation (http://www.mail-archive.com/pgsql-patches@postgresql.org/msg03400.html), so I wonder if there are any caveats or hurdles which would make me consider writing my own type.

Other than the fact that we'd feel free to change the behavior of any or
all of that with no notice?

aclitem is an internal type. If you depend on its behavior, you'll have
only yourself to blame if your application fails in the future.

(I probably wouldn't bother making this point, if the immediately
preceding message hadn't been from someone whining because we changed
the behavior of hashname() ...)

regards, tom lane