fix(prqlc, sort): do not require sort columns if it's followed by an aggregation

[julien-pinchelimouroux]

Fixes: #3200

sort always required sorted columns which caused an unwanted column selection in the next aggregate : column <SORTED_COLUMN> must appear in the GROUP BY clause or be used in an aggregate function

---

To fix it, it simply checks if an aggregate is present in the following transforms

---

I didn't find a PRQL query where this change can be a regression. If you have something in mind, please share it! 🙏

[max-sixty]

thanks @julien-pinchelimouroux !

would you mind adding a small test?

I didn't find a PRQL query where this change can be a regression. If you have something in mind, please share it! 🙏

could we use, from #3200

prql target:sql.duckdb
from tb1
sort {c0}
aggregate {new_col = min c1}

I also see lots of snapshot files in the diff — where are those from? (sorry if I'm missing something...)

[julien-pinchelimouroux]

Hello @max-sixty !

snap files comes from the following added tests :

• prqlc/prqlc/tests/integration/queries/sort_with_aggregation.prql
• prqlc/prqlc/tests/integration/queries/sort_with_aggregation_and_limit.prql

They are based on the reported query in the original issue #3200

[vanillajonathan]

Maybe a note should be added to the CHANGELOG file?

[max-sixty]

ah thanks @julien-pinchelimouroux !

could we slim down the test a bit, unless we really need two full integration tests? I'd have thought this could just be a single inline test in prqlc/prqlc/tests/integration/sql.rs ?

[julien-pinchelimouroux]

Hi @max-sixty
Yes you're totally right, that do not need a full integration test :)

[max-sixty]

great! thank you @julien-pinchelimouroux