F.2 Liste nécessaire

• Implementer la fonction: get_changed_tables(timeout,table1,table2,...)
• Implementer la fonction: LAST_UPDATED(nom_table)
• Modifications atomiques : y compris un langage réutilisable pour les procédures stockées.
• update items,month set items.price=month.price where items.id=month.id;
• Changer le mode de lecture des tables pour qu'elles utilisent les tables de mémoires (memmap) à chaque fois que c'est possible. Actuellement, seules les tables compressées utilisent une memmap.
• Ajouter un nouveau droit 'Show_priv' pour la commande SHOW.
• Rendre le code automatique des timestamp plus agréable. Ajouter timestamps dans l'historique de mise à jour avec l'option SET TIMESTAMP=#;
• Utiliser la lecture/écriture mutex à chaque fois que cela permet de faire gagner du temps.
• Ajouter le support des clés étrangères. On préférera peut être un langage procédural d'abord.
• Des vues simples : d'abord sur une table, puis sur des requêtes complexes).
• Refermer automatiquement une table si une table, une table temporaire, ou un fichier temporaire émet l'erreur 23 (not enough open files : pas assez de fichiers ouverts).
• Lorsqu'on rencontre un champs field=#, affecter toutes les occurences du champs field à #. Actuellement, cela ne fonctionne que pour les cas simples.
• Remplacer toutes les expressions constantes par des expressions calculées, lorsque c'est possible.
• Expression pour optimiser les clés. Actuellement, seuls key = field et key = constant sont optimisées.
• Ajouter quelques fonctions de copie, pour améliorer le code.
• Remplacer `sql_yacc.yy' par un analyseur inline pour réduire sa taille, et retourner des messages d'erreur plus parlants (5 jours).
• Modifier l'analyseur pour qu'il n'utilise qu'une règle par nombre d'argument différent d'une fonction.
• Utiliser les calculs complets de nom dans la clause d'ordre (Pour ACCESS97)
• UNION, MINUS, INTERSECT et FULL OUTER JOIN. (Actuellement seul LEFT OUTER JOIN est supporté)
• Permettre UNIQUE sur des champs qui peuvent être NULL.
• SQL_OPTION MAX_SELECT_TIME=# pour mettre une limite de temps à une requête.
• Inscrire l'historique de modification dans une base de donnes.
• Valeur négative pour que LIMIT commence à lire les résultats depuis la fin.
• Alarmes pour les fonctions clients client connect/read/write.
• Faire une version de mysqld qui ne soit pas multithreaded (3-5 jours).
• Notez le changement de safe_mysqld: suivant la norme FSSTND (que Debian essaie de suivre) les fichiers PID doivent être stockés dans `/var/run/<nom_du_programme>.pid' et les fichiers de logs dans `/var/log'. Il serait pas mal de pouvoir mettre "DATADIR" dans la première déclaration d'un "pidfile" et "log" : cela permettrait de modifier l'emplacement de ces fichiers d'une seule commande.
• Meilleure gestion des lignes à taille variable, pour éviter la fragmentation.
• UPDATE SET blob=read_blob_from_file('my_gif') where id=1;
• Permettre à un client d'enregistrer une requête.
• Ajouter l'utilisation de zlib() pour dégzipper les fichiers avec LOAD DATA INFILE.
• Finir de corriger le trie et le regroupement de colonne de type BLOB.
• Procédures stockées. Cela n'est pas prioritaire pour le moment, car les procédures stockées ne sont pas très standardisées. Un autre problèmes est que les véritables procédures stockées rendent la vite très difficile à l'optimiseur, et dans de nombreux cas, le rende plus lent. D'un autre coté, nous allons écrire un langage atomique et simple de modifications qui pourra être utilisé pour écrire des boucles et autres avec MySQL.
• Utiliser des sémaphores lors du compte des threads. Il faut qu'une librairie de sémaphore soit implémentée pour MIT-pthreads.
• Ne pas assigner de nouvelle valeur à une colonne de type AUTO_INCREMENT lorsque la valeur passée est 0. Utiliser plutôt le code NULL.
• Ajouter le support complet pour les JOIN avec parenthèses.
• Réutiliser les threads pour les systèmes avec de nombreuses connexions.

Le temps est donné en quantité de travail, et non pas en temps réel. Le coeur de métier de TcX's est l'utilisation de MySQL et non pas son developpement. Mais comme TcX est une société très souple, elle a attribué beaucoup de ressources au developpement de MySQL.