>> боюсь, сейчас меня пошлют... но объясните мне пожалуйста чем плоха идея >> диалекта SQL? Допустим мы создаем диалект 4, где SELECT из процедуры без >> SUSPEND запрещен, но оставляем диалект 3, где он разрешен. Где грабли? > > Грабли с диалектами будут при > эксплуатации.
В чем конкретно? Если мы пишем в документации "работает начиная с версии 2.0", то такое же описание "работает в диалекте 4" должно [теор.] иметь те же последствия. Существующие программы в любом случае указывают диалект 3. Новые, скомпилированые с новым ibase.h будут использовать диалект 4. Тогда можно будет ввести правило, что каждая major версия ФБ поддерживает новый диалект (основной) и диалект предыдущей major версии (но не больше). Я бы даже ввел правило, что с каждой новой major версией номер текущего диалекта увеличивается на 1. Таким образом разработчики при миграции на новую версию сервера будут также обязаны мигрировать SQL. Больших проблем в этом не вижу, так как major версии ФБ у нас чаще чем раз на 2 года не получается выпускать. Я пока вижу грабли только для разработчиков ФБ - увеличивается число "if sqlDialect == 4" в коде самого парсера. А еще учитывая общее желание извести BLR - будет непросто... Но опять, таки, я не слышал (хотя возможно пропустил) аргументов против виртуальной машины аналогичной BLR. Джим был категорически против, но деталей не объяснил... А посему у меня пока еще в голове крутится идея новой виртуальной машины (назвем ее например extendedBLR), где нет ощутимых ограничений на число встроенных ф-ций например, и каждый парсер парсит свой диалект SQL в новый eBLR. Роман --~--~---------~--~----~------------~-------~--~----~ -~----------~----~----~----~------~----~------~--~---
