On Mon, Aug 18, 2008 at 07:31:04PM -0400, Tom Lane wrote:
> 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 vaguely reminds me of Sybase's hidden primary keys.
> 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?
Informix has some pretty good blob-handling:
http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.sqlr.doc/sqlrmst101.htm
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
