David Fetter <david@fetter.org> writes:
> On Mon, Aug 18, 2008 at 04:22:56PM -0400, Tom Lane wrote:
>> The main things I think we'd need to consider besides just the
>> access API are
>>
>> - permissions features (more than "none" anyway)
> Would ROLEs work, or are you thinking of the per-row and per-column
> access controls people sometimes want?
Well, obviously roles are the entities that receive permissions, but
on what do we base granting permissions to LOs?
With the current model that a LO is an independent entity that is merely
referenced (or not) by OIDs in the database, it seems like we'd have to
grant/revoke permissions to individual LOs, identified by OID; which
sure seems messy to me. People don't really want to name their LOs
by OID anyway --- it's just a convention that's forced on them by the
current implementation.
I was kinda wondering about something closer to the TOAST model, where
a blob is only referenceable from a value that's in a table field;
and that value encapsulates the "name" of the blob in some way that
needn't even be user-visible. This'd greatly simplify the
cleanup-dead-objects problem, and we could avoid addressing the
permissions problem at all, since regular SQL permissions on the table
would serve fine. But it's not clear what regular SQL fetch and update
behaviors should be like for such a thing. (Fetching or storing the
whole blob value is right out, IMHO.) ISTR hearing of concepts roughly
like this in other DBs --- does it ring a bell for anyone?
regards, tom lane