Tom Lane wrote:
>
> Chris,
> This is to let you know that the core list has discussed this patch,
> and we feel that it is not appropriate to apply it at this late stage
> in the 7.0 development cycle.
Here you see Chris what happens when you try to force the default
behaviour be the "wrong" way :-p
But seriously, we could still warn people about current (mis)use of
inheritance and that it may be soon be changed/deprecated or "made
compatible with Informix" whichever seems most PC.
> There are several reasons for this:
>
> * It appears that making such a definitional change is still
> controversial. (One thing that still needs to be looked at is whether
> SQL 3 defines any comparable features,
It does define "comparable" features, but moves away from out nice clean
SQL92 worldview quite radically.
> and if so whether we ought
> to be following their syntax and behavior.)
I agree that some discussion about OQL vs. SQL3 would be in place.
> * The implications of changing this behavior still need to be followed
> through in the rest of the system. For example, it doesn't make much
> sense to me to change SELECT to have recursive behavior by default when
> UPDATE and DELETE can't yet do it at all. A user would naturally
> expect "UPDATE table" to scan the same tuples that "SELECT FROM table"
> does.
That's true. I would like to see INSERT,UPDATE,DELETE and SELECT be
updated together.
Fixing ALTER TABLE behaviour is not so important as we are just getting
most of it done for plain SQL92 by 7.0.
> * It's awfully late in the 7.0 development cycle to be making such a
> significant change. We have only ten days left to scheduled beta,
> which is not enough time to find and work out any unexpected problems
> that may be lurking.
Also - fixing object DB behaviours would give us reason to move to 8.x
faster ;)
> We encourage you to continue to work on this line of development,
> but with an eye to merging your code into CVS early in the 7.1 cycle,
> rather than trying to squeeze it into 7.0 at the last minute.
But could we then disable the current half-hearted OO for the time being
to avoid more compatibility problems from people who might err to use it.
If there is serious attempt to put the O back in ORDBMS we should not let
compatibility with non-SQL postgres extensions to be a decisive fact.
But then again that kind of change is best done at a major number change.
--------------------
Hannu