Maxim BogukЯ даже объясню почему у вас проблема:
вот у вас в базе есть 2 строки с:

"Field2" "Field3"
foo foo
foo bar

Куда именно надо сортировать "Field2"=foo? в начало списка или в конец списка?
Когда сможете ответить на это - тогда и сможете написать правильный запрос :).

Здесь нужно ставить вопрос не о том, куда сортировать поле (Field2"=foo), а о том, куда сортировать записи (foo / foo) и (foo, bar)
Сортируются ведь записи, а не поля.

Ответ : для правила сортировки ( ORDER BY CASE WHEN "Field2" = "Field3" THEN 1 ELSE 0 END )
сначала будет следовать запись (foo, bar), затем (foo / foo)

Далее выполняем SELECT-выборку поля Field2 (получаем две записи)
Далее выполняем DISTINCT "Field2" и получаем поле Field2 из первой полученной записи, т.е. из (foo, bar).

Далее возникает вопрос: в чём заключается логическая ошибка вот такого запроса, чтобы он генерировал ошибку:

Maxim BogukПотому что в SQL порядок выполнения операций другой... и ORDER BY делается в САМОМ КОНЦЕ (после него только LIMIT/OFFSET).
На момент ORDER BY в вашем запросе уже никакой информации о Field3 нет, у нас остался просто список уникальных Field2.Из ваших слов следует, что ORDER BY выполняется после SELECT и только по SELECT-полям.
Но это не так, иначе бы невозможно было выполнить запрос вида:


Следовательно, ORDER BY выполняется до SELECT-выборки и в т.ч. по полям, отсутствующим в предложении SELECT.
А это значит, что на момент ORDER BY есть информация не только о SELECT-полях, но и всех прочих полях записей (в частности, Field3 )

Ы2Посмотрите план такого запроса и увидите, что сначала выполняется выборка, а потом уже сортировка, которой доступны не только перечисленные в SELECT поля потому, что выборка выбирает не поля, а записи целиком .
Т.е. сначала выбираем, потом сортируем и только после отдаем те поля, что перечислены в SELECT. Так и я о том же.

Но Maxim Boguk пишет:автор На момент ORDER BY в вашем запросе уже никакой информации о Field3 нет , у нас остался просто список уникальных Field2Кто прав ?
Здравый смысл на нашей стороне, а вот PostgreSQL - на стороне Maxim Boguk ...