On Sat, Jun 9, 2018 at 12:22 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Jun 8, 2018 at 2:10 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> I don't understand this complaint. Before, the code took one >>> AppendRelInfo, and according to you, it was clear what was supposed to >>> happen. Now it takes an array of AppendRelInfos and, according to >>> you, it's completely unclear. Yet that seems, to me at least, to be a >>> straightforward generalization. If 1 AppendRelInfo is an adequate >>> specification of one translations, why are N AppendRelInfos not an >>> adequate specification of N translations? >> >> Because the relationships between the transforms are unclear. Are we >> supposed to apply those N transformations to the expression in sequence? >> It doesn't look to me like that's what the code does. I think --- I might >> be wrong --- that the code is relying on the transformations to be >> non-overlapping, that is a change made by any one of them cannot be >> further affected by another one. This is, however, undocumented. > > OK, I see. I guess that possible confusion didn't occur to me both > because I was looking at the code, which I knew wouldn't handle > overlapping transformations, and also because the intended use was for > partition-wise join, where the problem can't come up because we're > translating from the toplevel RTIs for the join to the set of RTIs > appropriate for one child-join. But, it's certainly fine to add a > comment.
That didn't occurred to me as well. Here's patch with comments and Assertions added to check the non-overlapping AppendRelInfos. The assertions check that same parent or child doesn't appear more than once in any of the AppendRelInfos, neither as a parent nor as a child. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
pg_arl_v2.patch
Description: Binary data
