Re: [RFC] Security label support
От | Stephen Frost |
---|---|
Тема | Re: [RFC] Security label support |
Дата | |
Msg-id | 20100527195710.GL21875@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: [RFC] Security label support (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [RFC] Security label support
(Tom Lane <tgl@sss.pgh.pa.us>)
|
Список | pgsql-hackers |
* Tom Lane (tgl@sss.pgh.pa.us) wrote: > Stephen Frost <sfrost@snowman.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
В списке pgsql-hackers по дате отправления:
Следующее
От: Stephen FrostДата:
Сообщение: Re: functional call named notation clashes with SQL feature