feat: Default to NULLS LAST

[max-sixty]

As discussed in #2601

[aljazerzen]

I've read the documentation you've written and realized that I don't support this option.

The DuckDB PR lists 4 options:

1. NULLS FIRST when ASC, NULLS LAST when DESC
2. NULLS LAST when ASC, NULLS FIRST when DESC
3. Always NULLS FIRST
4. Always NULLS LAST

They switched from option 3 to option 4. This PR is now also switching PRQL to option 4.

I'm suggesting we don't use any and force users to either:

• specify that their columns don't contain nulls or,
• use nulls_first or nulls_last ordering.

Justification became very long, so I'll open an issue about this. This PR can be merged not to stall the development, we can revert later.

[eitsupi]

Wondering if this change is a blocker of 0.9.0 release.
Do we merge this immediately? Or should we delay merging until #2622 is resolved?

[aljazerzen]

This is not a breaking change (we didn't guarantee position of the NULLs before), and will not be a breaking change if we remove it (we still don't guarantee position of the NULLs now). Because #2622 will take some time to be resolved fully, let's merge this now and update it later.

[max-sixty]

Until we decide, why merge? Possibly it's not technically a breaking change, but it's at least some churn.

I would favor reverting, releasing, and then continuing the discussion.

(Possibly I was keener on the change than you, so we're swapping positions here — arguably that's good!)

[aljazerzen]

I just don't like open PRs that are accumulating merge conflicts :D

[max-sixty]

OK, though I don't think that's the correct weighing of tradeoffs — churn in PRs is better than churn in our SQL output.

Even if we don't guarantee the sorted-ness of nulls, it's still going to change the output of some queries.

There are some parts of this we can keep, but until we make a decision would you object to reverting the bulk of it?

[aljazerzen]

churn in our SQL output

Stability of produced SQL was never part of our versioning guarantees.

[max-sixty]

Stability of produced SQL was never part of our versioning guarantees.

OK — but we surely still place some weight on the results that the query produces?

Possibly my reply of "SQL output" was unclear — I'm not worried about the SQL text per se — that has a very low weight in my mind. (We don't add random linebreaks! But otherwise...)

But if we went ahead with this, we'd have a note in our Changelog that says "Your queries will have different results because of the null sorting!", and then possibly another note next time stating "Actually we're back to the previous version!". Surely that seems bad — even if we don't guarantee null sorting (which isn't clear to me, but happy to accept it).

A curious aspect is I'm strongly mood-affiliated with your general perspective here! Move quickly, take some small pain to unblock the process, etc. But I I still place some weight on external churn. No?