Відповідно до обмежень на збережені підпрограми та тригери , не можна використовувати динамічний sql (обмеження знято для збережених процедур у версії 5.0.13 та пізніших версій). Чому це обмеження діє? І навіщо піднімати його на процедури, а не на функції чи тригери?
Відповіді:
Щойно почувши це питання, я змушує задуматися про два аспекти:
АСПЕКТ №1: Функції повинні бути ДЕТЕРМІНІСТИЧНІ
Якщо це так, це означає, що функція повинна послідовно представляти однакові дані повернення для заданого набору параметрів, НЕ МАТЕРІАЛИ, КОЛИ ВИ ВЗАЄМО ФУНКЦІЮ.
Тепер уявіть собі функцію, яка виробляє іншу відповідь через збирання даних у різний час доби на основі статичного SQL у функції. У певному сенсі це все ще можна вважати ДЕТЕРМІНІСТИЧНІМ, якщо ви кожен раз запитуєте один і той же набір таблиць і стовпців із заданим набором параметрів.
Що робити, якщо ви могли змінити основні таблиці функції за допомогою Dynamic SQL? Ви порушуєте визначення ДЕТЕРМІНІСТИЧНОЇ функції.
Зауважте, що MySQL додав цю опцію в /etc/my.cnf
log-bin-trust-function-creatorsХоча це може бути надмірним спрощенням, це дозволяє дозволити функціям записувати дані у бінарні журнали, не суворо виконуючи властивість DETERMINISTIC.
АСПЕКТ №2: Тригери повинні бути спроможні повернути назад
По суті, у вас є дані, які ростуть квадратично (навіть експоненціально) лише в MVCC. Процес управління відкатом SQL за допомогою тригерів, які можуть бути недетермінантними, був би нечесним чином складним.
Зважаючи на ці два аспекти, я впевнений, що розробники MySQL подумали про ці речі та швидко відхилили їх, встановивши обмеження.
Отже, навіщо скасовувати обмеження на процедури? Простіше кажучи, жодних проблем щодо ДЕТЕРМІНІСТИЧНИХ властивостей чи відкатів немає.
Це чудове запитання, але я не знаю відповіді. Я думаю, що для цього доведеться зайти до команди внутрішніх служб, але я не знаю, що вони зароблять на цьому сайті. Тим часом я можу допомогти вам вивести деякі відповіді.
Для початку я бачу це:
Кеш тригера не визначає, коли змінилися метадані базових об'єктів. Якщо в тригері використовується таблиця, і таблиця змінилася з моменту завантаження тригера в кеш, тригер працює з застарілими метаданими.
Що змушує мене думати, що це має щось спільне з цим. Перекомпіляція SQL не збирається, якщо вона навіть не контролює метадані. Що означає, що це турбота про двигун.
Таким же чином, коли я читаю цей блок, то думаю те саме (двигун):
Щоб запобігти проблемам взаємодії між потоками сервера, коли клієнт видає заяву, сервер використовує знімок підпрограм і тригерів, доступних для виконання оператора. Тобто сервер обчислює перелік процедур, функцій та тригерів, які можуть бути використані під час виконання оператора, завантажує їх, а потім переходить до виконання оператора. Це означає, що поки оператор виконується, він не побачить змін у підпрограмах, виконаних іншими потоками.
Так що я в цілому не зовсім впевнений, чому вони цього не дозволяють, але я можу здогадатися. Вибачте, що я не можу вам допомогти більше, я відкритий для того, щоб висунути це ще раз. Найкраще сподіватися на деякі активні розробки MySQL, коли ми залишимо приватну бета-версію;)
Багато в чому це пов’язано з безпекою. Виняток для процедур полягає в тому, що динамічному SQL в рамках процедури може бути призначений контекст безпеки користувача, що виконує. Це означає, що незважаючи на те, що двигун не знає, що буде виконуватися, він може переконатися, що користувачеві дозволено отримувати доступ до посилаються об'єктів.
Крім того, ви можете підняти потворні питання того, що може статися, якщо це було б допустимо.