> I guess the patch works fine, but what I'm saying is it might be limited to > small use cases. Another instance of this that I can think of is ORDER BY clause > of window specifications, which you may want to remove from the target list > as well, in addition to ORDER BY of query. It will just not be removed by this > approach, simply because it is looking at only parse->sortClause. Certainly > you can add more rules to the new function to look at the window specification, > but then I'm not sure what we are missing.
Yeah, I thought the extension to the window ORDER BY case, too. But I'm not sure it's worth complicating the code, considering that the objective of this optimization is to improve full-text search related things if I understand correctly, though general solutions would be desirable as you mentioned.
Ah, I see the use case now. Makes sense.
> So, as it stands it doesn't have > critical issue, but more generalized approach would be desirable. That said, > I don't have strong objection to the current patch, and just posting one thought > to see if others may have the same opinion.
OK. I'll also wait for others' comments. For review, an updated version of the patch is attached, which fixed the bug using the approach that directly uses the clause information in the parse tree.
I tried several ways but I couldn't find big problems. Small typo: s/rejunk/resjunk/
