в Oracle и MSSQL, если кому интересно, как и в MySQL — в ключ сортировки приходит неоткастованное значение. Вообще так логичней кмк...

Там каст в первой строчке был

SELECT id, 
       number::integer

можно и так записать

SELECT products.id, 
       CAST(ptcs.number AS integer)

SELECT id, 
       number::integer

SELECT products.id, 
       CAST(ptcs.number AS integer)

Да, я заметил, об этом и речь: постгрес в order by передаёт целочисленный результат, все остальные — нет, для сортировки по целому числу кастовать надо в самом order by, не в select

Вот, например, в Oracle (равно как в MySQL и MSSQL):

select to_number(num) from table2 order by num

сортировка будет произведена по строке, не по целочисленному значению

Для сортировки по строке как по числу это надо указать явно:

select * from table2 order by to_number

(num)

select to_number(num) from table2 order by num

select * from table2 order by to_number

да, действительно забавненько

мне как-то больше нравится кастовать в селекте,
кажется более читаемо так

никтож чужой код не любит читать, а тут в первой строчке я тип данных меняю)

мне вот другое интересно

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

типа констрейнт такой?))

https://i.stack.imgur.com/lrXCt.png

для меня, честно говоря, каст в селекте выглядит не очень явно...
Получается, что функции одного уровня иерархии имеют входные параметры как результат другой функции, того же уровня иерархии...
не очень очевидно, как мне кажется
Но это, безусловно, дело привычки.

забавно чувак в коменте пишет,
что орм-ка отказывается читать unsigned и signed целые числа в mysql

https://stackoverflow.com/a/11515613

я смотрю как другие в кодовой базе пишут, и пишу так же)
последовательно чтоб всё было, легко понималось

вот только все пишут по разному ...

я не про каст конечно, холиварим)

Как я понимаю, верхняя граница у unsigned больше в два раза...

Обычная практика int/uint во многих типизированных языках используется...

Это ты выдумал.

Ну как бы да,
обычная практика,
в go говорят: используй инт и забей

В mysql я пока только понял, что ты через ORM не сможешь воткнуть атрибут типа

user.add_order

если у тебя в ордерах повсюду unsigned

user.add_order

А нечего ормами пользоваться 😅 Я не в курсе какую там орм дает возможность, но знаю что через с обычным драйвером и каким-нибудь sqlx все работает на ура))

Что я выдумал? Что постгрес передаёт каким-либо образом трансформированное в селекторе значение дальше по цепочке, а другие РСУБД - нет? Другими словами, что в других базах (MySql, Oracle, MSSQL) значения в селекте иммутабельны в отличие от постгреса? Факты это подтверждают, все примеры приведены, пробуй.

Любая СУБД, если ей передать в order by таблица.поле отсортирует по этому полю, а если псевдоним - то по тому, что за этим псевдонимом скрывается

вообще о другом речь...

а...

Что прям "совсем о другом" это я загнул, да — в общем-то, вы правы, только вот какой нюанс в разных реализациях:
В PG, если полю  в явном виде не задавать алиас, то в order by всё равно придёт откастованное значение.

SELECT value::integer FROM test order by value

← отсортируется как по инту

Если же аналогичную конструкцию сделать в, например, Oracle:

select to_number(value) from test order by value

 ← отсортируется как по строке

Чтобы в том же Оракле сортировка прошла как по целому, алиас надо указывать явно:
select to_number(value) int_value from test order by int_value;