CBAC (content based access control), OIDs, auto fields - Mailing list pgsql-hackers

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. :