On Sun, 21 May 2000, Chris Bitmead wrote:
> Peter Eisentraut wrote:
> >
> > Chris writes:
> >
> > > I.e. "SELECT * FROM foobar*" becomes "SELECT * FROM foobar", and
> > > "SELECT * from foobar" becomes "SELECT * FROM ONLY foobar".
> >
> > This aspect of the patch I wholeheartedly agree on. The rest I'm not sure
> > about -- yet. :)
> >
> > > Benefits:
> > > *) SQL3 says it.
> >
I also agree about the usage of ONLY, as long as it follows the
official standardized SQL3 spec.
About returning multiple types of rows again: I don't see that in SQL3 so far
(difficult and time consuming to read). If it were allowed, you might have to
specify the level to dig to in the tree. The rows are shared among supertable
and subtables. One row in a leaf table has subrows in all its supertables up
the tree. If you do a "SELECT * FROM supertable*" (for example, if you were to
redefine table* to mean select heterogeneous rows), what row will you get for a
row that exists in a leaf? The same row is in all tables between supertable
and the leaf. I suppose it would be necessary to have the query check each row
and see how far down the tree it goes, or the system keeps track of that and
returns the row-type from the table that inserted it. OR, there could be some
extra specifier like "SELECT * FROM supertable DIGGING TO LEVEL 3". In this
case, it would only look down into the tree to 3 levels below supertable and
you'd never get row-types that are down lower than level 3. Anyhow, I still
don't think returning multple row-types is going to happen, not that I have any
authority one way or the other! :-)
--
Robert B. Easter
reaster@comptechnews.com