Robert Haas <robertmh...@gmail.com> writes: > If the parent is RTI 1, and the children are RTIs 2..6, what > varno/varattno will we use in RTI 1's tlist to represent a column that > exists in both RTI 2 and RTI 3 but not in RTI 1, 4, 5, or 6?
Fair question. We don't have any problem representing the column as it exists in any one of those children, but we lack a notation for the "union" or whatever you want to call it, except in the case where the parent relation has a corresponding column. Still, this doesn't seem that hard to fix. My inclination would be to invent dummy parent-rel columns (possibly with negative attnums? not sure if that'd be easier or harder than adding them in the positive direction) to represent such "union" columns. This concept would only need to exist within the planner I think, since after setrefs.c there'd be no trace of those dummy columns. > I think we have quite a bit of code that expects to be able to translate > between parent-rel expressions and child-rel expressions, and that's > going to be pretty problematic here. ... shrug. Sure, we'll need to be able to do that mapping. Why will it be any harder than any other parent <-> child mapping? The planner would know darn well what the mapping is while it's inventing the dummy columns, so it just has to keep that info around for use later. > Maybe your answer is - let's just fix all that stuff. That could well > be right, but my first reaction is to think that it sounds hard. I have to think that it'll net out as less code, and certainly less complicated code, than trying to extend inheritance_planner in its current form to do what we wish it'd do. regards, tom lane