Re: [GENERAL] Proposed Changes to PostgreSQL

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: chris(at)bitmead(dot)com
Cc: "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgresql(dot)org>, pgsql-sql(at)postgresql(dot)org, pgsql-general(at)postgresql(dot)org
Subject: Re: [GENERAL] Proposed Changes to PostgreSQL
Date: 2000-02-03 02:57:48
Message-ID: 200002030257.VAA00457@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers pgsql-sql

> 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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Chairudin Sentosa 2000-02-03 03:28:34 6.5.3 help
Previous Message Tom Lane 2000-02-03 02:55:19 Re: [SQL] Proposed Changes to PostgreSQL

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-02-03 03:10:13 Re: [HACKERS] SELECT FOR UPDATE leaks relation refcounts
Previous Message Tom Lane 2000-02-03 02:55:19 Re: [SQL] Proposed Changes to PostgreSQL

Browse pgsql-sql by date

  From Date Subject
Next Message The Hermit Hacker 2000-02-03 03:38:05 Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
Previous Message Tom Lane 2000-02-03 02:55:19 Re: [SQL] Proposed Changes to PostgreSQL