Твит от Rachel True:
Кто-нибудь еще сталкивался с подобной ошибкой в Apple iCloud ранее или в данный момент? Я уже 6 месяцев не могу найти решение и пытаюсь найти хоть какую-нибудь помощь.
Я припоминаю мертвые языки программирования как Кобол(Кобальт в оригинале) и это похоже на ошибку в коде, а не в устройстве.
Ага, т.е. они не санитируют поля, которые пользователь от руки вводит? Совсем ёбнулись? 😁
Смех смехом, а до сих пор можно на некоторых ресурсах положить поисковик, введя select * from dual;
Таблица из 1 строки. Можно использовать чтоб вывести к примеру дату, когда данные из бд на деле не нужны. Тогда можно вбить к примеру "SELECT Curdate() FROM Dual". Тогда выйдет 1 запись с датой.
Такой команды не существует, сейчас попробую обьяснить. Смотрите, суть SQL в том, что данные берутся из какой-то таблицы с данными. После SELECT указывается какие колонки, скажем так, мы берем, после FROM - из какой таблицы, и можно еще условия после WHERE и куча остального, но это не важно... Пример на картинке. Вверху сама таблица, и пример как получить ее всю в запросе. Если после SELECT указать имя колонки, то можно взять только ее. Но так же после SELECT можно указывать еще функции, получения даты к примеру - тогда она добавится во все строки в новую колонку. Можно указать ТОЛЬКО это функцию, но тогда она возьмется столько раз, сколько есть строк в таблице. По этому нужно брать dual, в которой всего 1 строка. (Можно в теории взять любую таблицу, и ограничить количество строк с помощью LIMIT 1 (возможно вы это и имели ввиду), но это плохой способ, потому что в таком случае перед применением LIMIT, СУБД все равно просмотрит все записи в таблице, и если таблица большая, то это будет лишняя нагрузка)
Спасибо за развернутый ответ.
Дело в том что мы используем Clickhousе, там секция FROM опциональна и команда SELECT now() вполне валидна.
Я думал в других современных бд так же.
А, сорян, я расписывал так ибо думал что вы не в теме :D А оказывается я сам не в курсе, что ж, теперь буду знать про clickhouse. Но вообще да, в других СУБД такого вроде нет (Хотя кто знает, может где-то еще есть... SQL вообще в разных СУБД разный, то что работает в одной, в другой просто нет)
Самый кайф, когда ты юзаешь ORM:
На мастере выбираешь диалект той субд, которая у тебя локально, и все работает.
На проде меняешь диалект, т.к. там другая субд, и нихрена не пашет.
Веселье незабываемое. <_>
Ну это уже выстрел в ногу. Потому что ORM может абстрагировать только самые базовые возможности SQL, а различия пойдут уже хотя-бы в настройках (или даже в наличии) collation. Не говоря о типах данных и их ограничениях.
SELECT без FROM не разрешается стандартом SQL, но тем не менее реализован во многих СУБД. Например в SQLite3, Postgres, MySQL и SQL Server запрос "SELECT 1, 2, 3;" нормально отработает и вернет значения.
А еще можно упороться и сделать вот так:
SELECT * FROM (VALUES ('AZAZAZA')) t1 (col1) WHERE 1 = 1;
Можно добавить что нативно есть в Oracle и MySQL, из крупных. В остальных БД либо можно эмулировать , либо оно нафиг не надо.
Долго привыкал когда после многих лет Оракла еще прибавились Teradata и BigQuery =)
Но зачем? Если это "защита", то это самое классическое "Security through obscurity" которое только можно придумать.
Twitter
10.8K постов8.2K подписчик
Правила сообщества
Запрещено:
1) Политические посты (автор будет блокирован, посты будут выноситься в общую ленту). Примечание: пост считается политическим, если на него установлен тег "Политика" автором поста, голосованием пользователей, или модератором Pikabu;
2) Посты, не связанные с тематикой сообщества (будут выноситься в общую ленту). Примечание: сообщество посвящено новостям и скриншотам, которые связаны с социальной сетью "Twitter";
3) Новостные посты не связанные с тематикой новостей про Twitter. Для них есть сообщество Новости.
--
При нарушениях правил сообщества вызывайте аккаунт
--
В остальном анархия в пределах правил Pikabu – они находятся в компетенции