Maximilian Roos

> deny it. We can make a nice error message saying "this may contain nulls, use `nulls_first` or `nulls_last`. A bit less convenient, but much more reproducible. FWIW I think...

> What do you think about defaulting to infer all columns as not-null? In such scenario, the error about "missing nulls_last" would only show up for columns that were explicitly...

> So the 3 viable options are: > > 1. `null < x` for every non-null x (this would be [DuckDB's option 1](https://github.com/PRQL/prql/pull/2617#issuecomment-1560839169)), > > 2. `null > x` for...

As discussed on dev call — we all quite liked "If it's not sortable, it goes at the end". This would imply `NULLS LAST` We're going to think more about...

I agree with these semantics! In these terms — what defines the ordering of the sub-arrays themselves? Why does the sub-array with nulls go last? A similar way of formulating...

Do we want to merge the `NULLS LAST`? Is this refining how we're conceptualizing it or making a decision on whether to proceed? (I'm happy to resuscitate that PR if...

FYI because of https://github.com/PRQL/prql/pull/2754#issuecomment-1586743241, this is no longer urgent / a blocker for 0.9.0...

Thanks @FinnRG . Yes, repro-ed. And a particularly bad error message... As a workaround in the meantime, this works: ```prql from s"SELECT * from group" ``` ```sql WITH table_0 AS...

Completely abstract of the current implementation, I do think that's a bit unfriendly / inconsistent. I recognize we do need to make some tradeoffs because of PRQL's use of "bare...

Thanks for the offer re a PR for the docs — we'd def accept it. If we do that, would be great to link to this issue and caveat —...