Robert Haas wrote:
On Tue, Aug 3, 2010 at 3:05 PM, Yeb Havinga <yebhavi...@gmail.com> wrote:
Yeb Havinga wrote:
The underlying cause is the failure of the code to recognize that if
relation C inherits from both A and B, where A and B both have column x,
that A.x 'is the same as' B.x, where the 'is the same as' relation is the
same that holds for (A.x, C.x) and (B.x, C.x), which the code does a lot of
trouble for to recognize. This means that if some definition is altered on
A.x, only C.x is updated and B.x not touched. IMO this is wrong and either a
multiple inheritance structure like this should be prohibited, since the
user did not explicitly declare that A.x and B.x 'are the same' (by e.g.
defining a relation D.x and have A and B inherit from that), or the code
should update parents of relations when the childs are updated.
Thinking about this a bit more, the name 'is the same as' is a bit
confusing, since that relation might not be commutative. C.x 'inherits
properties from' A.x, or C.x 'is defined by' A.x are perhaps better names,
that reflect that the converse might not hold. OTOH, what does C.x 'inherits
(all) properties from' A.x mean? If it means that for all properties P,
P(C.x) iff P(A.x), then C.x = A.x commutatively and by similar reasoning
A.x = B.x.
ALTER TABLE top1 RENAME COLUMN a_table_column TO another_table_column;
When looking for previous discussions that was referred to upthread, the
first thing I found was this recent thread about the exactly the same
problem http://archives.postgresql.org/pgsql-hackers/2010-01/msg03117.php
Sorry for the double post, however the previous discussion postponed work to
.. now, so maybe there is some value in first trying to specify exactly what
'inherits' means, and derive consequences for code behaviour from that.
Yeah, I was thinking about that thread, too, on my drive home from
Metuchen.
I just read that thread. In the beginning there is a short discussion
what the non-astonishing behaviour of the RENAME in the case of multiple
origin inheritance should be, which is preventing renames or any
property change in that case. I think we should explore the possibilty
of allowing the RENAME more.
What if on a RENAME of a column (maybe with a necessary explicit
CASCADE) in the multiple origin parent case, the parents with the same
columns are altered too? I don't think it is ashtonishing for users;
after all they've created the tree in the first place, but mostly for
programmers with some experience with inheritance in computer languages:
inheritance should go down, not up. That's why I tried to make reasoning
exact, to figure out why it would be ok (or not) to update another
parent as well. The reasoning can be made more formal/exact, but I
believe in its current form it makes a strong case to technically allow
to prograpage property changes to other parents as well (if they have
the same inherited column).
1. If you're changing properties of a column, you need to verify for
each relation in the inheritance tree that the "expected attinhcount"
and the actual attinhcount match. If, for any relation in the
inheritance tree rooted at the named table, they don't, then they are
doubly inherited there, from some other table outside the hierarchy
rooted at the named table, and the operation must fail.
If we want to block these RENAMES, yes. This is essentially KaiGai's
patch http://archives.postgresql.org/pgsql-hackers/2010-01/msg02878.php
2. If you're adding a column, you need to propagate the new column to
relations that don't have it yet, but if you find one that already has
it than you adjust attinhcount and don't recurse to its chidlren.
Sound ok.
3. If you're dropping a column, you essentially decrement the
attinhcount of all your children; then you recurse into any that reach
attincount = 0 and not attislocal and drop the column there as well.
This too.
regards,
Yeb Havinga
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
