Re: Extending varlena

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