Peter Eisentraut wrote:
>
> > > the `SELECT **' syntax (bad idea, IMO),
> >
> > Why is it a bad idea (considering that every ODBMS on the planet does
> > this)?
>
> First of all, ODBMS and [O]RDBMS are not necessarily infinitely compatible
> concepts. An ORDBMS is an RDBMS extended with OO'ish features such as
> table inheritance and abstract data types to make data modeling easier for
> those who like it.
And which may be ignored by those who don't, just like SELECT ** .
> But below it all there's still relational algebra and
> friends. An ODBMS is a paradigm shift to get rid of some restrictions in
> relational databases, both technical and theoretical, the implication of
> which is that it's no longer a relational database. Please correct me if
> I'm wrong.
Adding DATE and TIME datatypes or functions to SQL may have also seemed
a
paradigm shift but seems quite essential once it is done.
>
> Specifically, a query on a relational database always returns a table, and
> a table is a set of rows with the same number and types of columns.
Says who ? ;)
> This is a pretty fundamental assumption, and even accounting for the
> possibility that it might be broken somehow is going to be a major effort
> throughout the entire system.
In first round ** could we disallowed in subselects and other tricky
parts.
> Now a question in particular. I understand that this syntax might
> give me some rows (a, b, c) and others (a, b, c, d, e) and perhaps others
> (a, b, c, f, g, h). Now what would be the syntax for getting only (b, c),
> (b, c, e) and (b, c, h)?
What would you need that for ?
If its really needed we could implement something like
SELECT B,C,E?,H? FROM BASECLASS.
but as E can be an INT in one subclass and TIMESTAMP or VARBINARY in
other
it would perhaps be better to do
SELECT B,C,SUB1.E?,SUB3.H? FROM BASECLASS.
which means the attribute E defined in subclass SUB1 (an inherited by
its
descendants)
or perhaps
SELECT B,C,E OF SUB1,H OF SUB3 FROM BASECLASS.
to be style-compatible vith general verbosity and english-likeness of
SQL ;)
> Finally, it seems that the same effect can be obtained with a UNION query,
> padding with NULLs where necessary and perhaps judicious use of
> CORRESPONDING. What would be wrong with that?
It would be overly complex and error-prone and need a rewrite each time
a new
sub-class is added.
------------
Hannu
