ээээ... я думал, это очевидно... :)

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

представь, что у тебя есть текстовое поле или json (привет лингволео)
никто точно не знает сколько данных базе придется поднимать с диска. а если учесть, что часть данных может храниться отдельно от основной таблицы, то их не только поднять надо, но еще и найти.

а следующий ход - передача по сети.
т.е. у хорошего селекта должны быть
- перечисление полей
- order by
- limit

я имел ввиду есть ли какие то различия между * и перечислением полей если тебе нужны все данные?

различий нет. но схема базы может измениться. и select * вчера может быть совсем не тем, что select * сегодня

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

если добавил ничего не сломается, а просто начнет тормозить. а если тип поменялся или поле удалили, то сломается с гарантией

зависит от либ и языка, с дефолтным драйвером в го ломаетя

например, ты поменял в запросе join on на join using или простигосподи join natural, то даже если схема не менялась, тебя будет ждать сюрприз

а ну да, пардон

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

"order by" это ты погорячился

мы это обсуждали, пока ты был в отпуске )

в постгре нет сортировки по умолчанию

да и пофиг. если порядок не важен - не надо писать order by, может начать не те индексы использовать

if sorting is not chosen, the rows will be returned in an unspecified order

на базках по 100к строк нормально, на сотнях миллионах - надо сильно задуматься, перед тем как делать order by

и прекрасно)

При пагинации без order by будет очень грустно

"если порядок не важен"

ненормально, если у тебя запрос возвращает 100к сток )