While SQL3 talks about trees and leaf rows, it's not implemented like
that, so all this worrying about digging down trees and leafs is all a
bit mute.
"Robert B. Easter" wrote:
> 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
--
Chris Bitmead
mailto:chris@bitmead.com
http://www.techphoto.org - Photography News, Stuff that Matters
