On Sat, Jun 9, 2018 at 12:22 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Jun 8, 2018 at 2:10 PM, Tom Lane <tgl@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