Re: TODO: GRANT/REVOKE: Allow column-level privileges

On Fri, Jan 20, 2006 at 07:09:46PM -0500, Tom Lane wrote:
> kevin brintnall <kbrint(at)rufus(dot)net> writes:
> > * add OID column to pg_attribute. This permits dependencies to be
> > registered correctly in pg_shdepend.
>
> No, no ... the precedent in pg_depend is that columns are represented as
> the table's OID plus a column number. Please don't invent some random
> other notation for a column, especially not one that is so expensive to
> relate to the parent table. Add a subobject ID to pg_shdepend instead.

I was referring to the dependency that exists between a grantee and any
pg_attribute ACL entries that mention the grantee. When the role is
dropped, the ACL entries that mention that role have to be removed.

Specifically, I propose creating an entry such as the following in
pg_shdepend for every grantee G, for every column C in which G is
mentioned:

classid = AttributeRelationId /* 1249 */
objid = C.oid
refclassid = AuthIdRelationId /* 1260 */
refobjid = G.oid
deptype = 'a' /* SHARED_DEPENDENCY_ACL */

Are you suggesting that the pair (reloid,attnum) is superior for
identifying a pg_attribute entry? Are there any other possible uses for
pg_attribute.oid?

> > STILL LEFT TO DO:
>
> My recollection is that there's quite some deal of code that assumes
> pg_attribute rows are fixed-width. You will have some issues there.
> It's possible though that none of that code needs to access privileges,
> in which case you'd be OK just dropping off the ACL data from the
> in-memory copies of pg_attribute rows. Another possible solution is the
> pg_attrdef model, ie, keep the ACLs somewhere else.

I'm employing the same hack^H^H^H^Hmethod that is currently used in
pg_class.

--
kevin brintnall =~ <kbrint(at)rufus(dot)net>