SQL dynamique dans les routines stockées MySQL

Question

Selon les restrictions sur des routines stockées et les triggers , dynamique sql ne peut pas être utilisé (restriction levée pour les procédures stockées dans la version 5.0.13 et versions ultérieures). Pourquoi cette limitation en place? Et pourquoi soulever des procédures, mais pas de fonctions ou déclencheurs?

Answer 1

Le fait d'entendre la question me fait penser à deux aspects:

VOLET # 1: Les fonctions sont censés être déterministes

Si ce donc, cela implique qu'une fonction doit présenter les mêmes données de retour cohérente pour un ensemble donné de paramètres, peu importe quand vous appelez la fonction.

Maintenant, imaginez une fonction qui produit une réponse différente à cause de la collecte de données à différents moments de la journée en fonction de SQL statique dans la fonction. Dans un sens, qui peut encore être considéré comme DETERMINISTE si vous interrogez le même ensemble de tables et colonnes à chaque fois, étant donné le même ensemble de paramètres.

Et si vous pouviez changer les tables sous-jacentes d'une fonction via SQL dynamique? Vous violez la définition d'une fonction déterministes.

Notez que MySQL a ajouté cette option dans /etc/my.cnf

log-bin-trust-function-creators

Bien que cela puisse être trop simpliste de dire, ce qui permet des fonctions d'être autorisés aux données d'écriture dans les journaux binaires sans appliquer strictement la propriété déterministes.

VOLET 2: Les gâchettes doivent pouvoir être annulées

• Pouvez-vous imaginer un déclencheur avec tous les mêmes comportements en fonction et l'introduction dynamique SQL dans le mélange?
• Pouvez-vous imaginer essayer d'appliquer MVCC (Multiversion Concurrecy Control) contre SQL dynamique après l'application MVCC à la table de base le déclencheur a été conçu pour?

Vous aurait essentiellement des données qui pousse quadratiquement (même de façon exponentielle) juste à MVCC seul. Le processus de gestion de la restauration de SQL avec des déclencheurs qui peuvent être non déterministes serait complexe impie, pour le moins.

À la lumière de ces deux aspects, je suis sûr que les développeurs MySQL pensé de ces choses et les a rapidement rejeté en imposant des restrictions.

Alors, pourquoi lever la restriction pour les procédures? Autrement dit, il n'y a pas d'inquiétude sur les propriétés déterministes ou Rollback.

Answer 2

Ceci est une grande question, mais je ne sais pas la réponse. J'imagine que cela va devoir goto l'équipe internals, mais je ne sais pas qu'ils vont être grand dans ce site. En attendant, je peux vous aider à en déduire des réponses.

Pour commencer, je vois ceci:

  

Le cache de déclenchement ne détecte pas lorsque les métadonnées des objets sous-jacents a changé. Si un déclencheur utilise une table et la table a changé depuis le déclencheur a été chargé dans le cache, le déclencheur fonctionne en utilisant les métadonnées pas à jour.

Ce qui me fait penser que cela a quelque chose à voir avec elle. Il ne va pas être recompiler SQL si ce n'est pas le contrôle même les métadonnées. Ce qui signifie qu'il est un problème de moteur.

De même, quand je lis ce bloc, je pense la même chose (moteur):

  

Pour éviter des problèmes d'interaction entre les threads de serveur, lorsqu'un client a des problèmes de déclaration, le serveur utilise un instantané des routines et des déclencheurs disponibles pour l'exécution de la déclaration. C'est, le serveur calcule une liste des procédures, des fonctions et déclencheurs qui peuvent être utilisés lors de l'exécution de l'instruction, les charge, et procède ensuite à exécuter l'instruction. Cela signifie que si les exécute déclaration, il ne sera pas voir les modifications aux routines effectuées par d'autres threads.

Donc dans tout ce que je ne suis pas tout à fait sûr pourquoi ils ne le permettent pas, mais je peux deviner. Désolé que je ne peux pas vous aider plus, je suis ouvert à sussing ceci un peu plus. Le mieux est de l'espoir pour certains développeurs de MySQL actifs une fois que nous quittons version bêta privée;)

Answer 3

En grande partie, elle est due à la sécurité. L'exception pour les procédures est parce que le SQL dynamique au sein de la procédure peut être attribué le contexte de sécurité de l'utilisateur d'exécution. Cela signifie que même si le moteur ne connaît pas ce va être exécuté, il peut s'assurer que l'utilisateur est autorisé à accéder à l'objet référencé (s).

Au-delà, vous pouvez soulever les questions laides de ce qui pourrait arriver, était-il permis.