Re: Learning curves and such (was Re: pgFoundry) - Mailing list pgsql-hackers

* Alvaro Herrera (alvherre@surnet.cl) wrote:
> > I havn't actually gotten anything real into PostgreSQL *yet*, but I've
> > been spending a fair bit of time on implementing support for SQL Roles
> > and have had alot of help developing the approach for best implementing
> > it (thanks Tom!) and help with stupid questions (what's a tuple?) from
> > a couple developers on IRC (thanks Neil!  thanks Andrew!).
>
> Say, how are you doing on that front?

Current status is- it now compiles with a few pieces still missing:

Better parser/backend setup needs to be done.  I've hacked 'create role'
into place where 'create group' was, but really I need to sit down and
think about the *correct* statements, looking at the standard, etc,
and write those and the associated back-end parts (most of the back-end
parts are already done I think).  Once those are done and implemented
I'll see about backwards compatibility to the create user/create group
parts.

pg_group and associated views (information_schema, etc).  We don't
currently have an aggregate-into-array function that I saw so either
we'll need to write one or we'll have to fake the information in
pg_group (as, say, just the first group you're in, or something).  This
is only for backwards-compatibility to things which used pg_group so I'm
not sure how important it is for it to be fully functional.  I *think* I
updated all the information_schema views to not use pg_group but to use
the new system tables and that they're implemented correctly.  I'm
trying to think but there might be another view that was involved in
this but I'm not sure.

Write the base-case (no cache available) 'in_role' lookup code.  I
expect this code will also be used during role assignment to verify
there are no loops.  'in_role' currently works for the one-level case,
but doesn't handle the multi-level case.  Shouldn't be too hard to do.

Per-connection cacheing code for 'in_role' information.  Discussed
this with Tom, basically it'll be similar to the search_path cacheing
code which is in namespace.c where the cache is marked out of date
and regenerated whenever there's a change to the pg_auth_members
table.  Don't expect this to be very difficult.  Once this is done
the 'in_role' code in the ACL system will need to be updated for it.

flat-file startup updating.  This is what I'm currently working on.  The
difficulty is that I want the flat-files to have only names but the
role/member information is in terms of Oids which need to be looked up
to role names.  Since this is during startup code now the syscache isn't
available.  What I'm doing is building a copy of the tables in memory
(since they should be reasonably small), qsorting them and using bsearch
for the lookups.  Since they're in memory already and the
write-new-role-information situation is much less common than startup I
think I'm also going to qsort based on role name and define the format
of the pg_auth table to be already-sorted so that the startup code
doesn't need to sort it.

Once I get all of the startup code working and can actually *connect* to
the database I'll be doing a great deal more testing, bug fixing, and
implementing the remaining items and testing them.
Thanks,
    Stephen