On Mon, Sep 29, 2014 at 11:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Michael Paquier <michael.paquier@gmail.com> writes:
> > On Sat, Sep 27, 2014 at 1:57 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> We could probably hack solutions to these problems without changing the
> >> AppendRelInfo data structures, but I'm wondering if it wouldn't be a good
> >> idea to redefine them or at least add more fields to make it easier to
> >> work with multi-level appendrel ancestry.
>
> > Hm. Something like oldest_parent_reltype and oldest_parent_relid when
> > defining it? IMHO it would be nice to avoid simple hacks if possible but is
> > changing AppendRelInfo really something back-patchable at this point?
>
> It seems unlikely that any extensions are creating these structs for
> themselves. So I think we could safely add fields at the end in back
> branches. We've done that before in other planner structs.
OK. So I have been able to put my head into that and using the
multiple tips given out by Tom I have finished with the patch
attached. The fix done is rather simple: when creating a AppendRelInfo
entry for a join (pull_up_union_leaf_queries) or a union
(expand_inherited_rtentry), I added a new field in AppendRelInfo to
track the top-level parent, value that is afterwards used in
generate_implied_equalities_for_column when a child relation is
checked.
Patch contains as well a regression test with UNION ALL and a join.
Also, I imagine that the new functions I introduced would make more
sense in a different file, and that perhaps the new variables are not
correctly named, if you have any thoughts just let me know and I'll
update the fix. Regression tests are passing, but it may be possible
that some other code paths are broken, in this case I guess that we
could improve the fix by covering those other code paths as well with
additional regression tests. Also, I think that it would make sense to
track as well the composite type Oid of the top-level parent, I have
just not added it yet because it did not seem necessary for this
particular patch, just let me know your thoughts on the matter.
Note that this patch fixes as well the test case reported here:
http://www.postgresql.org/message-id/2326379.AOuSqtNClj@klinga.prans.org
Regards,
--
Michael
