From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Chris <chris(at)bitmead(dot)com>, Postgres Hackers List <hackers(at)postgresql(dot)org> |
Subject: | Re: OO Patch |
Date: | 2000-05-21 19:19:53 |
Message-ID: | 392836D9.E7C33461@tm.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Matthias Urlichs | 2000-05-21 20:37:21 | Re: MySQL's "crashme" (was Re: Performance) |
Previous Message | Chris | 2000-05-21 18:54:18 | Re: Thus spoke SQL3 (on OO) |