Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL

Chris Bitmead wrote:
>
> Tom Lane wrote:
>
> > > 1) An imaginary field in every tuple that tells you the class it came
> > This is a good idea, but it seems to me that it'd fit into the system
> > traditions better if the pseudo-field gave the OID of the source
> > relation.
>
> This was my initial thought too, but then it occured to me that SQL
> doesn't normally deal in oids. For example you don't do a DROP TABLE
> oid;

DROP TABLE (SELECT relname FROM pg_class WHERE oid=the_oid);

would be cool ;)

> > > I would propose that that anytime you do a SELECT * from a base table
> > > that you would get back the full rows from those sub tables.

Maybe SELECT ** FROM BASE would be more flexible as it leaves the standard
SQL with its "standard" meaning ?

> > Frankly: ugh. This doesn't square with *my* ideas of object
> > inheritance. When you are dealing with something that ISA person,
> > you do not really want to hear about any additional properties it may
> > have; you are dealing with it as a person and not at any finer grain of
> > detail. That goes double for dealing with whole collections of persons.
> > If you want to examine a particular member of the collection and
> > dynamically downcast it to some more-specific type, the proposed
> > classname/classoid feature will give you the ability to do that;
> > but I think it's a mistake to assume that this should happen by default.
>
> This would be the case if the database were the whole world. But it is
> not,
> it is a repository for applications written in other languages. How can
> you
> "dynamically downcast to a more specific type" if the database hasn't
> returned
> the columns of the more specific type? How can I instantiate a C++
> object of
> type "Student" if the database has only returned to me the data members
> of type
> "Person"?

You could do as some DB's (IIRC Oracle) do with large objects - return the
whole row if doing a select that has many rows.

return just a handle when going over a cursor with FETCH 1 and then have
calls to get the rest.

We will have to change the API sometime not too distant anyway, the current
api is unable to deal with anything that does not have a nice textual
representation (like an image or sound) in spite of all the talks about
easy extensibility - the extensibility is all in the backend, ther is no
easy way to get new datatypes in/out.

---------------
Hannu