Re: [SQL] Re: [GENERAL] Proposed Changes to PostgreSQL
От | Chris Bitmead |
---|---|
Тема | Re: [SQL] Re: [GENERAL] Proposed Changes to PostgreSQL |
Дата | |
Msg-id | 3898FC60.E4436ED5@nimrod.itg.telecom.com.au обсуждение исходный текст |
Ответ на | Re: [GENERAL] Proposed Changes to PostgreSQL (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > >>>> 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. > > My thought also. If we had a *real* object orientation, then a returned > column would have an abstract data type that might correspond to an > object supertype. Of course that just pushes the problem down a level: > how does the application know what methods the returned object has? > How can it even invoke those methods --- whatever code might exist > for them would live on the server, presumably, not get shipped around > in query results. In (most) ODBMSes, the code for a class does NOT live in the database server. (How would you store a C++ binary in a database?). What happens is when a query returns an object, some magic behind the scenes checks the type of the returned object (thus the need for the "classname" column or similar.) The magic behind the scenes then instantiates a C++ object of the correct class and populates all the data members from the query results. The application code is then free to make polymorphic calls on the object because ALL the fields are populated, not just those of the base class.
В списке pgsql-hackers по дате отправления: