Chris Bitmead writes:
> > That also goes for the various ALTER TABLE [ONLY]
> > syntax additions. If I add a row to A only then B is no longer a subtable
> > of A.
>
> I agree that the alter table only is crazy, but the functionality was
> there before and I didn't want to be the one to take it out. But if
> someone does I can't imagine I'd object.
Okay, I think I see what you're getting at. The "ONLY" syntax on DELETE,
UPDATE, and ALTER TABLE would provide an entry point for the current,
broken behaviour, for those who need it (though it's not really backwards
compatibility per se). We might want to flag these with warnings "don't do
that" and reserve the option to remove them at a later date, to save
people from attempting stupid things.
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. What I was also
wondering about were these things such as the "virtual" IDENTITY field
that was proposed, the `SELECT **' syntax (bad idea, IMO), and the notion
that a query could return different types of rows when reading from an
inheritance structure (a worse idea, IMO). I didn't know whether the patch
touched that. (I think now that it doesn't.)
I'll tell you what, I have some time next week, and I'll read up on SQL3.
Perhaps I'll survive it. ;-)
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
