Re: ERROR: ORDER/GROUP BY expression not found in targetlist

On Thu, Jun 16, 2016 at 12:16 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Jun 16, 2016 at 8:00 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>>> 1. The case originally reported by Thomas Munro still fails. To fix
>>> that, we probably need to apply scanjoin_target to each partial path.
>>> But we can only do that if it's parallel-safe. It seems like what we
>>> want is something like this: (1) During scan/join planning, somehow
>>> skip calling generate_gather_paths for the topmost scan/join rel as we
>>> do to all the others. (2) If scanjoin_target is not parallel-safe,
>>> build a path for the scan/join phase that applies a Gather node to the
>>> cheapest path and does projection at the Gather node. Then forget all
>>> the partial paths so we can't do any bogus upper planning. (3) If
>>> scanjoin_target is parallel-safe, replace the list of partial paths
>>> for the topmost scan/join rel with a new list where scanjoin_target
>>> has been applied to each one. I haven't tested this so I might be
>>> totally off-base about what's actually required here...
>>
>> I think we can achieve it just by doing something like what you have
>> mentioned in (2) and (3). I am not sure if there is a need to skip
>> generation of gather paths for top scan/join node. Please see the patch
>> attached. I have just done some minimal testing to ensure that problem
>> reported by Thomas Munro in this thread is fixed and verified that the fix
>> is sane for problems [1][2] reported by sqlsmith. If you think this is on
>> right lines, I can try to do more verification and try to add tests.
>
> You can't do it this way because of the issue Tom discussed here:
>
> https://www.postgresql.org/message-id/16421.1465828862@sss.pgh.pa.us

Something like what you have there might work if you use
create_projection_path instead of apply_projection_to_path.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company