Re: OO Patch

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