>> З.Ы.: Грешно так говорить, но меня не покидает мысль, что те, кто не использует подготовленные запросы, должны страдать, потому что это настолько эффективное и простое решение...Те, кто не использует prepared statements, страдать обязаны.
> Кстати, припомнилось ещё одно затруднение при использование prepared statement в mysql.
> Нетрудно представить себе ситуацию, когда появляется запрос типа
> SELECT * FROM T WHERE code IN ('1','2','4');
Это только на первый взгляд. Вред таких запросов не очевиден, но есть. До сих пор бегают пара-тройка перловых скриптов, которым на вход IN может иногда попасть несколько сот параметров. Или даже тысяч, редко. Вместо ожидаемых единиц. :(
> использовать вариант типа
> PREPARE stmt FROM 'SELECT * FROM T where code IN ?;';
> в доступной мне версии нельзя («Parameter markers can be used only where
> data values should appear, not for SQL keywords, identifiers, and so
> forth»).
MySQL не умеет массивы. Функций, подобных UNNEST, в MySQL нет и, пока, не предвидется. А если я не ошибаюсь - и не будет. После того, как мускуль был выкуплен Ораклом, надежд на мускуль совсем мало. Добавление нового объекта хранения(гео-данные) в INNODB-стор - это вообще отдельная песня. SQLite - отличное решение для небольших баз там, где невозможно/затруднительно разворчивание постгреса.
IMHO. Опыта работы с SQLite совсем мало. Про FTS ихний читал, интересно, рекомендую всем, кто хочет FTS использовать.
> можно
> PREPARE stmt1 FROM 'SELECT * FROM T where code IN (?);';
> PREPARE stmt2 FROM 'SELECT * FROM T where code IN (?,?);';
И не будет никогда, КМК. Парсер применяется при подготовке выражения, гонять его для каждого параметра - не самый оптимальный вариант.
> и т.д.,
> но это уже из области "страдать" к пользователям подготовленных запросов, не находите?
MySQL - прибежище адептов ORM, ибо просто, относительно предскауемо и достаточно стабильно. Любители ORM ОБЯЗАНЫ страдать. Хотя, конечно, допускаю исключения.
