CBAC (content based access control), OIDs, auto fields

Vadim said:

> You could use PG triggers on Updates, Deletes and Inserts (to insert
> owner user name) and try to use RULEs to rewrite SELECT statement.
> (I never played with RULEs...)

Perhaps if it can be done easily with rules, and then the 
method can be published -- but I have to wonder about using 
features that even the hardcore developers have never played 
with :-)   I guess I was hoping for some kind of specific
support in the core.

If CBAC were supported in a straightforward, easy way in PG it 
would be a major "selling" point imho.  We could say "and
PostgreSQL supports content-based access control..." 

		----------------------------

On the related subject, I like oids.  They are very useful.  
But I *also* want table-specific autonumbering (monotonic 
integer series in which gaps do indicate deleted records) and 
I'd really prefer that it be provided automatically as a table 
creation option, rather than having to write the same darn 
trigger N hundred times (as I have using the older 
Sybase engines).  

In fact, while I'm dreaming:  why not have a set of *three*
table creation options?  
	-recno 	causes an autonumber field to be prepended 
		to each record.  
	-user	causes the user ID of the inserting process 
		to be prepended to each record.  
	-stamp	causes the timestamp at insert time to be 
		prepended.  
The fields could have fixed names (like oid), say "recno",
"user", and "stamp" -- or as a luxury option the user could
supply their names as part of the option syntax:
	-user uid -stamp itime -recno seqno  

Like oid, these fields would *not appear* in result streams 
unless explicitly included in the FSE.  'select *' would not 
reveal them, but 'select oid,recno,user,stamp,*' would show 
all fields. (If these options are specified at table create 
time, then all subsequent inserts to that table automatically 
fill the special fields, without the user or developer having 
to know or care.) 

Of the couple of hundred tables I've designed and deployed in 
various apps over the last 5 years, perhaps 10 or 20 have 
*not* needed these fields.  I've cut-n-pasted the same darn 
boilerplate code a couple of hundred times to implement these 
fields on all the other tables.  If I could specify a few 
simple options on 'create table' instead, so much drudgery 
would be eliminated! And users would not see the "bookkeeping" 
fields by default.  Sounds heavenly to me.  

Once you imagine that automatic entry options of this sort 
exists, then CBAC seems like a logical accompaniment, 
available only on those tables where the UID auto-stamp has 
been selected at create time. It would be just one more 
option:  CBAC: Y/N. If Y, then the uid field is checked 
against the owner of the select query and the filtering done 
as described in my last post to HACKERS.

This seems (to me anyway) like a killer value-added feature,
something that would make PG so-o-o-o attractive for real,
practical, bread-n-butter app development.  How hard would 
it be?  (I know, that's the most annoying question anyone 
can ask a developer).

Am I alone in thinking this would be incredibly cool and
worth some effort?  I would love to see PG be demonstrably
BETTER than the commercial competition in several specific
areas (then maybe I could get approval to use it for
production work) and this looks like a good opportunity.

de

.............................................................................
:De Clarke, Software Engineer                     UCO/Lick Observatory, UCSC:
:Mail: de@ucolick.org | "There is no problem in computer science that cannot: 
:Web: www.ucolick.org |  be solved by another level of indirection"  --J.O. :