Re: [RFC] Security label support

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > I agree that we need to address this. I am kind of curious how this is
> > handled for comments? It appears to be, but I don't see an entry in
> > pg_depend when a comment is added to an object, yet the entry in
> > pg_description disappears when a table is dropped. <Shrug>
>
> IIRC, dropping comments is hard-wired into the object drop mechanism ---
> this seemed more efficient than having to add a pg_depend entry for each
> one. You could argue that either way of course depending on how many
> comments you expect there to be in the system.

ok. We would need to add similar mechanics for labels (removing the
entries when the table is dropped). Strikes me as slightly odd that we
have an infrastructure in place to handle exactly that but we're not
using it. :)

> I'm not real sure that you want a dependency for a security label anyway
> --- wouldn't that mean each label could only be used for one object?

Err, your question comes across to me like "if you added comments to
pg_depend, you'd only be able to use a given comment X for one object?".
Doesn't make alot of sense. :) Perhaps I misunderstood, but my
assumption would be that, as with comments, there would be an additional
identifier in pg_seclabel (eg: oid) to then use in pg_depend to track that
a given *entry* in pg_seclabel depends on a table. You wouldn't (erm,
and couldn't) put the actual text of the label into pg_depend.

The structure for pg_seclabel we were talking about would be very
similar to pg_description, eg:

CREATE TABLE pg_seclabel (
objoid oid not null,
classoid oid not null,
objsubid integer not null,
label text
);

We could move label into another table (eg: pg_labels) and then give an
OID to each label and then store the label's OID in pg_seclabel. That
would then have the problem you describe, but we could just have a
'mapping OID' from the table to the label and then have *that* depend on
the table (erm, and the label). I'm not sure I see the need for that
right now. We may want that when we add row-level security support, so
perhaps we should consider doing that now, but I don't expect RLS
anytime real soon.

A thought that did occur to me is that we could forgo actually
identifying in pg_depend the *specific* entry in pg_description or
pg_seclabel that depends on the table and, perhaps, just have an
entry that says "something with this classid depends on it, so delete
anything in that table which has a matching objoid and classoid of
what's being removed".

Thanks,

Stephen