I was previewing what I had written so far and I pressed submit by mistake. So I'm continuing on from my previous post.
I have to admit though that It's hard generalize what I see in the core code to applications that are under development or will be developed in the future, so we might see alot of use of deep inheritance structures where pg's inheritance mechanisms might turn out to be a huge performance win. It seems that acs_objects will be used extensively for cotent that is generated on the site, so in theory the acs_objects table will grow to be quite large over time on a busy site, so we really make sure we get this right.
So as I see it we can boil it down to a choice between a possible performance gain, which so far is unquantified, through the use of pg's inheritance versus the extra porting work that will be involved in using a different method for implementing acs_objects. If we use pg's inheritance method, we significantly raise the bar on our porting effort, and we will also be requiring people that port modules to learn quite a bit more about how the data model works, before they can effectively port a module to openacs 4.x. If we don't use pg's inheritance model, then porting is a simple mechanical process of substituting postgresql sql for oracle sql constructs. In addition future ports to interbase or other db's will be simpler if we don't use pg's inheritance methods.
