Caveat to this and all my future messages. I'm a newbie inexperienced in postgresql, Oracle, acs and porting issues and a "know nothing and don't want to" re Tcl and AOLserver.
Just bypassed sql/oracle permissions problem with:
cvs checkout openacs-4/packages/acs-kernel/sql/postgresql
Still wading through a lot of background.
Seems to me that missing from above discussion of Pg extensions is *rules* - assuming the rules system works "as advertized" and is not broken (I wouldn't know).
Focus on *inheritance* may miss central point that you can abstract the entire api for a postgresql database to make it look entirely like plain vanillla SQL2 with simple tables that are really "writable views" using the rules system. I believe that could even include maintenance of metadata like the kernel by rules that trigger creation of necessary inheritance indexes etc and work with the extensive built in catalog facilities that hold *everything* about a postgresql database and already provide most of the metadata needed.
Surely that would make it far easier for package developers to interface to. They would just be working with what appear to be ordinary "tables", doing ordinary CRUD and not having to think much
about the plpgsql magic behind the scenes.
Now that a prototype kernel is available (when permissions fixed 😉
there is a "working" base necessary for investigating other
approaches. Even if it turns out that rewriting existing queries
is a nuisance when porting other packages, it would be far more
difficult trying to do it later. Should get that done, or at least
carefully investigated, for the kernel now, before it becomes a
"lost opportunity".
This has obvious implications for portability - but can be looked at as targeting for future convergence on SQL3. aD was the *stronghold* of "who needs objects". Everything is going to get more and more OO
and aD is going to get heavily into java "middleware" contrary to
"the book". It would be a real shame for a project that has
expertize in a truly ORDBMS that can put most of the data abstraction
right inside the database engine (plus much of the "business logic")
to sacrifice that for an illusory attempt to straddle divergent
approaches.
As mentioned, ACS4 makes heavy use of Oracle views. Postgresql
essentially has fully *writable* views provided the necessary
framework is setup for package developers to use them. That
could make an *immense* difference.
