Якщо не хочеш бути першим - не вставай в чергу!
Я точно не пам'ятаю вже, давно з FB працював. Але, з усіх відомих мені SQL-БД - MySQL єдина база, з тих, що винайшли "Свій SQL з блекджек і. Своїм форматом LIMIT'а".
Ось, знайшов цитату, щодо FireBird 1.5:
Firebird повністю підтримує SQL-92 Entry Level 1 і реалізує більшу частину стандарту SQL-99 c деякими дуже корисними доповненнями. Це включає вираження DML / DDL, синтаксис об'єднань FULL / LEFT / RIGHT [OUTER] JOIN, вираження UNION, DISTINCT, підзапити (IN, EXISTS), вбудовані функції (AVG, SUM, MIN, MAX, COALESCE, CASE.), Обмеження цілісності (PRIMARY KEY, UNIQUE, FOREIGN KEY), і все загальні типи даних SQL.
Дотримуючись вище написаного, і тому, що Postgres так само реалізує більшу частину цих стандартів, запити повинні працювати і в FireBird і в Postgres, практично без змін. Крім того, наскільки я пам'ятаю, в FireBird (принаймні так було в версіях 1.5 і 2.х) так само як і в Postgres використовуються "послідовності". замість MySQL'евского AUTOINCREMENT'а.
Підводячи підсумок, хочу сказати, що Вам потрібно шукати не те, чим синтаксис FireBird'а відрізняється від MySQL'евского, а те, чим MySQL'евскій-SQL відрізняється від стандартів SQL.
Так, ніякого автоінкремента, також як і в постгрес, але це вже не до запитів, а до самої архітектури БД, швидше за все.
LIMIT 1, 2 - MySQL, пишеться в кінці запиту
LIMIT 2 OFFSET 1 - PostgreSQL, пишеться в кінці запиту
FIRST 1 SKIP 2 - FireBird, пишеться після SELECT
Це реально незручно, якщо робити пагінацію сторінок, наприклад. Але це мала частина біди, адже у них таких "булочок" реально багато. Взяти, приміром, конкатенацію: замість GROUP_CONCAT () там функція LIST (), яка не має стільки опцій, як GROUP_CONCAT (), наприклад, немає можливості вказати порядок зчеплення подстрок - для цього доведеться подавати на вхід відсортоване потік, а це значить, що потрібно використовувати ще одну функцію.