Exteris,

домножай значение, приведённое к числу, на плюс единицу или минус единицу (параметр) и сортируй по результату :-)

кстати, хорошо бы оптимизатор умел применять индексы по выражениям для order by column * :Param - ибо параметр тут для запроса константа

kdv,

ну причёт тут списки?

функции y=x и y=-x - две очень узко определённых случая, которые к спискам никак не относятся.

kdv,

чем это по сути отличается от ....WHERE ID = 1 через параметр?

а тем более, от ....WHERE ID = 1 OR 1 IS NULL через параметр?

кроме того, что одно Firebird уже умеет и все привыкли, а другое - ещё нет и все привыкли

-------

hvladя вообще не понял

печально

полноценную поддержку сортировки по подходящему индексу запросов типа select .... order by ? * (field1+field2), и как частный случай select .... order by ? * field1

это умножение, такая операция арифметическая

order by - это указание отсортировать результат выборки в стандарте SQL

(field1+field2) - это пример арифметического выражения, использующего поля таблицы ("field" по-английски "поле"). Причём, одной и той же таблицы оба поля, потому что не указаны ни алиасы таблиц ни их названия.

> order by не использует "подходящие индексы"?

когда как

select * from t2 order by id
PLAN (T2 ORDER PK_T2)

select * from t2 order by id desc
PLAN SORT ((T2 NATURAL))

select * from t2 order by cast (:direction as integer) * id -- параметр равен +1
PLAN SORT ((T2 NATURAL)) -- а лучше бы было PLAN (T2 ORDER PK_T2)

Кстати, ещё забавное в 2.5 (вероятно и 3, не пробовал) и IBE

select * from t2 order by id * :x
Data type unknown.

интересно, почему unknown, если id integer?

Симонов Денис,

я знаю, и в тикете про однонаправленность написано. Показать я хотел - разное поведение, именно что индекс иногда применим, а иногда нет.

более того, я знаю, и что планы в текущей реализации строятся при prepare, когда значений параметров ещё нет, и что вариантных планов в FB нету. Именно поэтому тикет оформлен как improvement, а не bug

прочитай наконец тикет, он гораздо короче "методов доступа". Речь идёт про четкий случай, где id = +1 либо -1 либо 0

впрочем, твой случай "если в direction передать число такое что результат вылезет за диапазон" implementaiton details вполне можно свести к той же тройке вариантов

- брать signum(direction): исходно SQL - математическая абстракция, и конечного диапазона у чисел нет.

А реализации SQL должны стараться выдать математически-коррeктный результат и свободны в выборе внутренней реализации. Соотвественно, переполнение при умножении тут не имеет значения, потому что результат клиенту не отдается, он только внутренне используется для сортировки.

результат сортировок order by +0.0001 * id и order by +1 * id и order by +1000 * if совпадает, поскольку зависит только от знака

и оптимизатор, поэтому, сохраняя математически корректный результат сортировки, имеет право эти выражения менять одно на другое

и да, для любителей "заставить сортировать после натурала, несмотря на существующий индекс" останется order by id+0

Симонов ДенисAriochинтересно, почему unknown, если id integer?

да неужели? А double не может быть?

а он в обоих случаях может, и в случае явного CAST тоже, почему бы нет?

впрочем, это уже будет третья ветка разговора, ну её к лешему

Ariochслучай, где id = +1 либо -1 либо 0

не id, а SQL-параметр конечно