Bruce Momjian wrote:
> So the field is created on the fly to show what table it came from.
> Seems like a good idea, though implementing another usually-invisible
> column will be tough.
What problems do you forsee?
> However, because it is not really a column like
> the oid is a column, it should be ok. Of course, internally it is
> relid.
>
> > 2) Changing the sense of the default for getting inherited tuples.
> > Currently you only get inherited tuples if you specify "tablename*".
>
> Sounds fine to me. Just realize you are taking on a long-overdue but
> big job here.
I already have a patch for this one. The change is a few pretty simple
changes
to gram.y.
> > 3) The ability to return different types of rows from a SELECT. This
> > is to allow implementation of ODBMS functionality where a query could
> > be required to instantiate objects of differing types with differing
> > attributes.
>
> This bothers me. We return relational data, showing the same number of
> columns and types for every query. I don't think we want to change
> that, even for OO.
What aspects bother you? This is the fundamental important thing about
object databases.
It's also something that I'm always wanting to do when generating web
pages.
I have web links like http://foo.com/page?id=123. I want to retrieve
the webpage object (which is an inheritance hierarchy) of id=123 which
may
represent a web page of different types. Then process appropriately for
different objects. i.e. typical OO polymorphism.
> How are you going to return that info the the client side?
Well the backend <-> frontend protocol that used to be able to return
tuples of different types would be put back in.
Also the berkerly postgres docs had other scenarios where different
tuples
could be returned. One is you could have a field of type postquel called
say
EMP.hobbies which had a value of "retrieve HOBBIES.all where...", and
then "retrieve
EMP.hobbies would return tuples of different types of hobbies.
