Oracle представили MySQL 5.6: http://www[dot]opennet[dot]ru/opennews/a[dot][dot][dot][dot]shtml?num=36031
Из очень примечательного:
полнотекстовые индексы в innoDB
explain для insert, update, delete (MySQL становится похож на взрослую СУБД? )
возможность добавлять индексы и менять структуру таблиц innodb без полного копирования таблицы и сопутствующей блокировки на запись
много чего полезного заявлено по производительности

Хоть и очень печальные тенденции по закрытию самого процесса разработки, но добавлены хорошие возможности.

Думаю всем стоить переходить на ExtraDB или MariaDB. А так новость немного радует

esterio, согласен. Ну, спустя некоторое время форки перетянут новшества.
Можно сразу и на postgres уходить

Вот насчет postgres у меня есть вопрос
сложно ли переходить после mysql?
Я понимаю что ето SQL, но все же

В приложении? Я, например, могу сменить в конфигурационном файле название драйвера БД (с PDO_MYSQL) - одну строку - и готово. Использующие паттерн адаптера тоже так могут.

EuGen
Дело в том что я пользуюсь mysqli. И еще мне не нужн оменять существующий проект. Так для личного опита скорее всего. Но вот только никогда никаких дел с ним не имел. Поетом у спрашиваю

Ну так ответ и дан - для общего случая. Ничто не мешает Вам использовать паттерн адаптера, чтобы инкапсулировать обращения к БД. И какая будет уже реализация (mysql/mysqli или postgree) - все равно.

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

Это Вы переходите на уровень БД, я же писал о

- соответственно, если использовать ORM для бизнес-процессов, которое как раз-таки в общем случае не имеет представления о низкоуровневой реализации в SQL, то изменение приложения действительно ограничится одной строкой. Это, разумеется, при условии, что приложение уже содержит в себе реализацию для всех предполагаемых драйверов (кивок в сторону Zend)
Особенности реализации тех или иных вещей в разных СУБД нужно будет уже учитывать при развертывании БД, возможной перестройке структуры или индексов и/или связей и т.п. - но код приложения здесь уже не будет затронут.

Значит я все таки неправильно вопрос задал. Но думаю я уже понял. Меня интересовало различия в синтаксисе. Но если можно без проблем написать адаптер - значить различия минимальны

С проблемами, сэр, но можно, люди ж пишут )))

Отличненько.

А подбирать правильный план для запросов типа SELECT xxx FROM tbl1 WHERE indexedField IN(SELECT value FROM tbl2 WHERE someCondition), где someCondition не ссылается на поля внешнего запроса - научился?
В смысле что такие запросы при выполнении другие СУБД выболняют как join, а не как exists.

а можно взять ADODB и сразу писать переносимый код без всяких адаптеров и ORM

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