From: Chris Bitmead <chris@bitmead.com>
To: Robert B. Easter <reaster@comptechnews.com>
Cc: Peter Eisentraut <peter_e@gmx.net>
Cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: Thus spoke SQL3 (on OO)
Date: Mon, 22 May 2000 09:03:27 +1000
Message-ID: <39286B3F.F4594E40@bitmead.com> (raw)
References: <Pine.LNX.4.21.0005201507330.423-100000@localhost.localdomain>
<00052104000003.14806@comptechnews>
<392830DA.B5546EF7@bitmead.com>
<00052108053904.14806@comptechnews>
"Robert B. Easter" wrote:
> I guess the major difference is that the hierarchial-model does not
> support multiple inheritance.
I don't agree. From SQL3...
"To avoid name clashes, a subtype can rename selected components of the
representation inherited from its direct supertypes."
and if that doesn't clinch it...
"Let the term replicated column mean a column appearing in more than one
direct supertable of T that is inherited by at least one of those direct
supertables from the same column of a single higher-level supertable."
That sounds like multiple repeated inheritance to me.
> Passing different row types to the
> client from one select, forces that client to be like the C++ function
> programmed in advance to deal with some derived class too.
You are assuming that the client application will be responsible for
dealing with these differences. What really happens is that a query is
more like a List<Baseclass> in C++. As long as you only call methods
contained in Baseclass on each element of the List, you are ok.
But those "virtual" methods you call need real objects to work with.
They need ALL the attributes in other words. The piece of language
infrastructure that behind the scenes instantiates all the C++ objects
as they fall out of the database can't create abstract Baseclass
objects. It needs all the attributes to instantiate Subclass objects, so
that the application code needn't know about different classes.
I suggest you download an evaluation copy of an ODBMS and have a play,
it will probably become clear.
> By sending the differing row
> types, the procedure that processes the rows might end up expecting child rows
> more than parent rows, even though you are using SELECT * FROM parent. The
> different rows are processed differently. If programmers become accoustomed
> to obtaining the child-type rows by selecting parent, they might eventually
> mistake a parent to be ISA child when one is received.
Whether a programmer is likely to make such a mistake depends more on
the programming language used. In an ODBMS situation almost all object
retrievals are not via an explicit query, but rather by object
navigation. You might have
class Purchase {
Link<Customer> buyer;
List<StockItem> items;
}
Result<Purchase> r = Query<Purchase>::select("select * from purchase");
Iterator<Purchase> i = r.iterator();
while (i.hasNext()) {
Purchase *p = i.next();
Customer *c = p.buyer;
Iterator<StockItem> = p.items.iterator();
// etc.
}
Any one of Purchase, Customer or StockItem might really be some
sub-class of those classes for all the application knows. But the behind
the scenes infrastructure needs to have all the attributes so that the
application code need not know.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: chris@bitmead.com, reaster@comptechnews.com, peter_e@gmx.net
Subject: Re: Thus spoke SQL3 (on OO)
In-Reply-To: <39286B3F.F4594E40@bitmead.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox