These are not that strange. When a dataset is made, ordering happens on the produced dataset. In the case of ``` SELECT * FROM t a JOIN t b ORDER BY s; ``` You first get a full dataset (or however it is named internally) that has one s column (in the same way if it was aliased), so ordering the dataset by the s column is pretty easy and probably the reason why the QP doesn't trip up on it, and most importantly, MUST produce the correct result. Trying to do: ``` SELECT 1 FROM t a JOIN t b ORDER BY s; ``` Produces no such s column in the produced dataset, so the ordering has to dig into a or b to find the referenced column to order by, but now it appears in both, and so it cannot assume and reports the ambiguity. However, if my explanation holds water in any way - it seems that ... ORDER BY length(s); in the original example should also work. It probably trips up somewhere in the maze of decisions the QP has to check/make. I won't call it a bug until one can show the SQL produced the wrong output. An error NOT produced where the context makes sense, yet other DBs would throw an error, is not a bug, it's a feature. Until of course the SQL result data is wrong.