What I want is that when I get objects back from multiple relations
(usually because of inheritance using "*" although I guess it could be a
union too), is to know the name of the relation (or class) from which
that object came.
So if I do a select * from person*, some of the resulting rows will have
come from person objects, but some may have come from employee objects,
others from the student relation.
So the query...
SELECT relname FROM person*, pg_class where person.classoid =
pg_class.oid;
does a join between a particular inheritance hierarchy (person in this
case), and the pg_class system table which contains a string name for
each relation.
In an ODMG interface library, what would really happen is at startup I
would find all the classes available from the system tables and cache
their structure. Then some application using the ODMG library would,
let's say it's C++, execute something like...
List<Person> = query("SELECT oid, classoid, * FROM person*");
and get a C++ array of objects, some of which may be Student objects
some of which may Employee objects etc. The internals of the ODMG
library would figure out which results were students and which were
employees by the classoid attribute of each resulting row and
instantiate the appropriate type of class.
The way I think this should probably be done is by having each row in
the entire database have an imaginary attribute called classoid which is
the oid of the class to which that object belongs.
In my own application right now, I actually have a real attribute called
(class oid) in a common base class, which is a foreign key into the
pg_class system table. This is wasteful and potentially error prone
though, since postgres knows which tables the rows came from (since each
relation is stored in a different file).
I don't think this can be done now within postgresql. Do you see what I
mean?
Tom Lane wrote:
> I am not sure what you mean by "class membership" here. There is type
> information for each column of every relation in pg_attribute and
> pg_type. There is also a pg_type entry for each relation, which can be
> thought of as the type of the rows of the relation. The query you show
> above looks like maybe what you really want to get at is the inheritance
> hierarchy between relations --- if so see pg_inherits.
>
> I suspect that whatever you are looking for is already available in the
> system tables, but I'm not quite certain about what semantics you want.
>
> regards, tom lane
--
Chris Bitmead
http://www.bigfoot.com/~chris.bitmead
mailto:chris.bitmead@bigfoot.com