Re: [GENERAL] Proposed Changes to PostgreSQL

> 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?

Well, it is usually pretty strange to carry around a column that doesn't
exist through all the code and finally contruct it at the end. I would
suspect something in the rewrite system could do that pretty easily,
though. That is the direction I would go with that.

>
> > 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.

OK, you will have to canvas the general list to make sure this does not
break things for people, though our inheritance system needs an overhaul
badly.

>
> > > 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.

I fear it is totally against the way our API works. How does someone
see how many columns in the returned row?

> > 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.

Yikes. Strange. Can we just return nulls for the empty fields?

How many new API calls are required?

--
Bruce Momjian | http://www.op.net/~candle
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026