Robert Haas <robertmhaas@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