Tom Lane wrote:
>
> Peter Eisentraut <peter_e@gmx.net> writes:
> > I guess what I might have alluded to with "design document" is that you
> > would have explained that connection, because I did look at the old
> > thread(s) and didn't have any clue what was decided upon.
>
> AFAIR, nothing was decided on ;-) ... the list has gone 'round on this
> topic a few times without achieving anything you could call consensus.
Oh dear. I thought we had progressed further than that. I hope we're not
back to square one here.
> I think Robert Easter might have his hands on the right idea: there
> is more than one concept here, and more than one set of applications
> to be addressed. We need to break things down into component concepts
> rather than trying for a one-size-fits-all solution.
I can't see that anything I've proposed could be construed as
one-size-fits-all.
1) DELETE and UPDATE on inheritance hierarchies. You actually suggested
it Tom, it used to work in postgres (if you look at the V7.0 doco very
carefully, it still says it works!! though it probably hasn't since the
V4.2 days). It's really a rather obvious inclusion.
2) Imaginary classoid field. This is a very stand-alone feature, that I
didn't hear any objections to.
3) Returning of sub-class fields. Any ODBMS *must* do this by
definition. If it doesn't, it isn't an ODBMS. The only question is what
syntax to activate it, and I'm not much fussed about that.