Oliver Elphick wrote:
> It would be wrong to mix these columns into one, because their meanings are
> different. If you were to `select status from person*' which column should
> be shown?
ERROR: Ambiguous column - Organization::status, Employee::status.
> You are right to say that all data should be retrievable, but wrong in
> wanting to attach descendant features to an ancestor class.
If the database were the whole world - maybe. But people use languages
to program databases. With a sort-of object database like PGSQL, an
object language would seem an obvious choice.
But there is no simple way to write a language integration interface so
that you could... say SELECT * from person* and instantiate appropriate
C++ classes complete with ancestor attributes for ancestor classes.
Maybe a new syntax would be appropriate, select ** from person*, the
"**" meaning to select all the attributes from the subclasses as well as
the specified classes.
This would then be used by a funky C++ language binding to instantiate
different C++ objects for different types of rows that come back.
> In this example, if I want a list of contacts, I must `select contact from
> organisation*', because person does not have a contact field. I lose
> nothing thereby, because there is no information to be got from any other
> sub-trees about contact.
You lose something, which is the ability to write a C++ language binding
that looks something like
Collection<Person> c = query("SELECT ** from person*);
and have any person decendants to have all their correct attributes
instantiated.
I'd love to see a project to give postgres an ODMG (Object Database
Management Group) standard interface for various languages. The guts of
postgres clearly has all the fundamentals, but a few details like this
would have to be added.
--
Chris Bitmead
http://www.bigfoot.com/~chris.bitmead
mailto:chris.bitmead@bigfoot.com
