Re: [QUESTIONS] inheritance questions

Started by Oliver Elphickover 27 years ago4 messages
#1Oliver Elphick
olly@lfix.co.uk

Olivier Caron wrote:

in the user's guide (chapter _ inheritance), i see :
-----------------------------------------------------------
select * from cities *

here the * after cities indicates that the query should be run over cities
and all classes below cities in the inheritance hierarchy.
Many of the commands that we have already discussed -- select, update
and delete -- support this * notation, as do others, like alter
-----------------------------------------------------------

i don't succedeed in to execute update or delete with this * notation,

The ramifications of inheritance are not well thought out in PostgreSQL.

Consider:

cities -----+---- capital_cities ----- megacities
¦
+---- regional_centres
¦
+---- small_towns

At the moment, a subclass inherits columns and _some_ constraints from
its parents - it inherits check constraints but not primary key constraints.
I don't know what behaviour is planned for foreign key constraints.
It is possible, with multiple inheritance, to inherit mutually-inconsistent
check constraints but there is no way to undefine or redefine inherited
constraints.

You can do `select * from cities *', but you cannot do an insert, delete
or update. In other words, the inheritance tree as a whole is regarded as
a read-only entity.

The inability to do insert seems reasonable, because there
would not be any safe way of knowing which table in the inheritance
tree was intended. However, update and delete could be expected to
work. I suspect that no-one ever asked for the facility!

I have previously suggested some syntax for specifying the inheritance
of constraints more precisely. It looks as if there should also be a
means of saying whether a descendant class should be included in
operations on multiple rows - I don't think it should be a facility that
operates automatically.

Is any of the developers an expert on the inheritance features? or is
this something that no-one has yet taken up?

--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"If it is possible, as much as it depends on you, live
peaceably with all men." Romans 12:18

#2Thomas G. Lockhart
lockhart@alumni.caltech.edu
In reply to: Oliver Elphick (#1)

Is any of the developers an expert on the inheritance features? or is
this something that no-one has yet taken up?

I think no one yet. I have thought about taking it up after finishing
(?) the type conversion issue, but that is in the future if at all...

- Tom

#3Bruce Momjian
maillist@candle.pha.pa.us
In reply to: Oliver Elphick (#1)

I have previously suggested some syntax for specifying the inheritance
of constraints more precisely. It looks as if there should also be a
means of saying whether a descendant class should be included in
operations on multiple rows - I don't think it should be a facility that
operates automatically.

Is any of the developers an expert on the inheritance features? or is
this something that no-one has yet taken up?

This is the most complete specification of inheritance limitations I
have read, and plan to keep it for inclusion in the TODO list.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)
#4Maurice Gittens
mgittens@gits.nl
In reply to: Bruce Momjian (#3)
Re: [HACKERS] Re: [QUESTIONS] inheritance questions

The inability to do insert seems reasonable, because there
would not be any safe way of knowing which table in the inheritance
tree was intended. However, update and delete could be expected to
work. I suspect that no-one ever asked for the facility!

This and similar points have been pointed out by a number of poeple (usually
in general terms) however somehow it seems OO features are of lower priority
for now.

Regards,
Maurice.