Hannu Krosing <[EMAIL PROTECTED]> writes: > I'd propose that ADD ONLY would pull topmost attislocal up (reset it > from the (grand)child) whereas plain ADD would leave attislocal alone.
ADD ONLY? There is no such animal as ADD ONLY, and cannot be because it implies making a parent inconsistent with its children. (Yes, I know that the code takes that combination right now, but erroring out instead is on the "must fix before release" list. Ditto for RENAME ONLY.) > The use of ONLY with this meaning is for the symmetry with DROP ONLY. But it's not a symmetrical situation. The children must contain every column in the parent; the reverse is not true. Some asymmetry in the commands is therefore unavoidable. >> I would find it quite surprising if I could destroy c.f2 by adding >> and then dropping p.f2. > This should depend on weather you drop ONLY I disagree. Your analogy to a CASCADE foreign key is bad, because the foreign key constraint is attached to the column that might lose data. Thus you (presumably) know when you create the constraint what you are risking. Losing existing child data because of manipulations done only on the parent --- perhaps not even remembering that there is a conflicting child column --- strikes me as dangerous. It seems like an indirect, "action at a distance" behavior. Here is another scenario: suppose p has many children, but only c42 has a column f2. If I "alter table p add column f2", now p and all the c's will have f2. Suppose I realize that was a mistake. Can I undo it with "alter table p drop column f2"? Yes, under my proposal; no, under yours. In yours, the only way would be to do a DROP ONLY on p and then retail DROPs on each of the other children. This would be tedious and error-prone. If some random subset of the children had f2, it'd be even worse --- it would be difficult even to identify which children had f2 before the ADD operation. IMHO this is a good example of why attislocal is useful. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org