In base alle restrizioni su routine e trigger memorizzati , non è possibile utilizzare sql dinamico (restrizione sollevata per le procedure memorizzate nella versione 5.0.13 e successive). Perché esiste questa limitazione? E perché sollevarlo per le procedure, ma non per le funzioni o i trigger?
Risposte:
Basta ascoltare la domanda mi fa pensare a due aspetti:
ASPETTO 1: Le funzioni dovrebbero essere DETERMINISTICHE
In tal caso, ciò implica che una funzione dovrebbe presentare gli stessi dati di ritorno in modo coerente per un determinato set di parametri, NESSUNA QUESTIONE QUANDO SI CHIAMA LA FUNZIONE.
Ora, immagina una funzione che produce una risposta diversa a causa della raccolta di dati in diversi momenti della giornata in base a SQL statico nella funzione. In un certo senso, ciò può ancora essere considerato DETERMINISTICO se si interroga ogni volta lo stesso set di tabelle e colonne, dato lo stesso set di parametri.
E se fosse possibile modificare le tabelle sottostanti di una funzione tramite Dynamic SQL? Stai violando la definizione di una funzione DETERMINISTICA.
Notare che MySQL ha aggiunto questa opzione in /etc/my.cnf
log-bin-trust-function-creatorsSebbene ciò possa essere una semplificazione eccessiva, ciò consente alle funzioni di scrivere dati in registri binari senza applicare rigorosamente la proprietà DETERMINISTIC.
ASPETTO # 2: i trigger dovrebbero poter essere ripristinati
Avresti essenzialmente dati che crescono in modo quadratico (anche esponenziale) solo nel solo MVCC. Il processo di gestione del rollback di SQL con trigger che possono essere non DETERMINISTICI sarebbe a dir poco complesso.
Alla luce di questi due aspetti, sono sicuro che gli sviluppatori MySQL hanno pensato a queste cose e le hanno rapidamente respinte imponendo restrizioni.
Quindi, perché revocare la restrizione per le procedure? In poche parole, non vi è alcuna preoccupazione per le proprietà DETERMINISTICHE o il rollback.
Questa è un'ottima domanda, ma non conosco la risposta. Immagino che questo dovrà andare alla squadra interna, ma non so che saranno grandi in questo sito. Nel frattempo, posso aiutarti a dedurre alcune risposte.
Per cominciare vedo questo:
La cache trigger non rileva quando sono cambiati i metadati degli oggetti sottostanti. Se un trigger utilizza una tabella e la tabella è cambiata da quando il trigger è stato caricato nella cache, il trigger funziona utilizzando metadati obsoleti.
Il che mi fa pensare che questo abbia qualcosa a che fare con esso. Non verrà ricompilare SQL se non sta nemmeno monitorando i metadati. Ciò significa che è una preoccupazione del motore.
Allo stesso modo, quando leggo questo blocco penso la stessa cosa (motore):
Per evitare problemi di interazione tra i thread del server, quando un client emette un'istruzione, il server utilizza un'istantanea delle routine e dei trigger disponibili per l'esecuzione dell'istruzione. Cioè, il server calcola un elenco di procedure, funzioni e trigger che possono essere utilizzati durante l'esecuzione dell'istruzione, li carica e quindi procede all'esecuzione dell'istruzione. Ciò significa che mentre viene eseguita l'istruzione, non vedrà le modifiche alle routine eseguite da altri thread.
Quindi, tutto sommato, non sono del tutto sicuro del perché non lo permettano, ma posso immaginare. Mi dispiace non poterti aiutare di più, sono aperto a dedurlo ancora un po '. La cosa migliore è sperare in alcuni sviluppatori MySQL attivi una volta che avremo lasciato la beta privata;)
In gran parte, è dovuto alla sicurezza. L'eccezione per le procedure è perché all'SQL dinamico all'interno della procedura è possibile assegnare il contesto di sicurezza dell'utente in esecuzione. Ciò significa che anche se il motore non sa cosa verrà eseguito, può assicurarsi che all'utente sia consentito accedere agli oggetti di riferimento.
Oltre a ciò, puoi sollevare le brutte questioni di ciò che potrebbe accadere, se fosse consentito.