Re: OO Patch

Hannu Krosing wrote:
>Peter Eisentraut wrote:
>> Now a question in particular. I understand that this syntax might
>> give me 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 syntax for 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 in one 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 in certain 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 independent of
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 specified and 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(dot)Elphick(at)lfix(dot)co(dot)uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"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; Always bearing
about in the body the dying of the Lord Jesus, that
the life also of Jesus might be made manifest in our
body." II Corinthians 4:8-10