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 по дате отправления: