Re: OO Patch

Поиск
Список
Период
Сортировка
От Oliver Elphick
Тема Re: OO Patch
Дата
Msg-id 200005220955.e4M9tfJ03405@linda.lfix.co.uk
обсуждение исходный текст
Ответ на Re: OO Patch  (Hannu Krosing <hannu@tm.ee>)
Ответы Re: OO Patch  (Marten Feldtmann <marten@feki.toppoint.de>)
Список pgsql-hackers
Hannu Krosing wrote: >Peter Eisentraut wrote: >> Now a question in particular. I understand that this syntax might >>
giveme some rows (a, b, c) and others (a, b, c, d, e) and perhaps others >> (a, b, c, f, g, h). Now what would be the
syntaxfor getting only (b, c), >> (b, c, e) and (b, c, h)? > >What would you need that for ? 
 
In OO terms it should be illegal.  In terms of any one class, there is a
defined set of columns that can be seen.  What Peter is asking for is a union
of selects on different classes.  The ordinary union rules should apply.
 >If its really needed we could implement something like > >SELECT B,C,E?,H? FROM BASECLASS. > >but as E can be an INT
inone subclass and TIMESTAMP or VARBINARY in >other 
 

I don't think that should be allowed.  It violates inheritance principles,
since the types are not compatible.


There is quite a lot right with inheritance as it is.  We support multiple
inheritance, and columns with the same name are merged in the child.  What we
immediately lack are features to make inheritance properly useful:

* shared index - an index that should point to the correct child class for quick recovery of rows from inheritance
hierarchies.
 

* inheritance of constraints, including Primary/Foreign keys (does this imply the necessity of turning inheritance off
incertain cases?)  
 

* handling of some write operations on a hierarchy: DELETE and UPDATE (INSERT must require the exact class to be
specified)

* automatic use of inheritance hierarchies (use ONLY to avoid it)

* ALTER ... ADD COLUMN inserting columns in the correct positions in child tables; alternatively, have column numbering
independentof the physical representation, so that columns can be added at the end but shown in the correct place by
SELECT.


There are further complexities in OO which might be desirable, but would
require a lot of design work.  One fundamental feature of pure OO is that
classes carry their own methods, whereas SELECT (for example) imposes a
global operation on the various classes of the inheritance tree.  This
makes the following problematic:

* renaming columns in multiple inheritance (to avoid column merging, or to allow a child's column to be of a different
type)- what would SELECT do with them?
 

* deferred classes - tables that are used only for inheritance rather than for storing data rows - how could these be
specifiedand implemented?
 

No doubt further research would bring up many more examples.

I'm not sure it is feasible to make PostgreSQL into a proper OO database,
but getting those first five features would really be useful.



-- 
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver              PGP key from public servers; key
ID32B8FAA1                ========================================    "We are troubled on every side, yet not
distressed;we      are perplexed, but not in despair; persecuted, but not     forsaken; cast down, but not destroyed;
Alwaysbearing     about in the body the dying of the Lord Jesus, that      the life also of Jesus might be made
manifestin our      body."        II Corinthians 4:8-10 
 




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Hannu Krosing
Дата:
Сообщение: Re: Postgresql OO Patch
Следующее
От: Chris Bitmead
Дата:
Сообщение: Re: Thus spoke SQL3 (on OO)