mysql transforme "binary" en "collate utf8_bin", qui coince quand on veut remettre ca dans sqlit. filtrons le aussi.

'timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP'
il faut couper le ON UPDATE que sqlite ne supporte pas ici

Dans create_base, on peut passer un nom de base prefixe par un path, qui est prioritaire sur _DIR_DB
Dans la connexion, on peut preciser un path dans le parametre $addr

Généralisation du 8e argument de la fonction spip_connect_db: on accepte maintenant un tableau de longueur 1: 'nom d'authentification' => 'fichier de connexion',
l'ancien format "chaîne de caractères" étant toujours pris en charge avec son a priori que le nom de l'authentification est "ldap".
Ce 8e argument est mémorisé dans l'index "authentification" de la globale "connexion" décrivant l'installation.
Cette mémorisation du 8e argument est effectuée par spip_connect_db qui ne le transmet plus aux fonctions de portage SQL qui n'auraient en fait jamais dû le recevoir.

Le débusqueur donne à présent aussi pour les requêtes fabriquées par le compilateur la ligne où l'erreur intervient dans le squelette (cas assez rares où l'utilisateur écrit mal des opérandes de fonctions SQL comme REGEXP). Occasion de voir que les portages SQL n'étaient pas toujours cohérents> de l'un à l'autre mais aussi en interne:

	* sql_countsel ne contrôlait pas bien une éventuelle erreur de sql_select, 
	* sql_errno ne retournait pas toujours un code numérique.

On rajoute dans le code compilé l'envoi du contexte de compil (toujours la même fonction {{{denoncer_inclure_dynamique}}} qui n'est donc toujours pas bien nommée), et un test de requête fautive pour éviter une cascade d'erreur ensuite.

La fonction {{{sql_select}}} voit son dernier argument légèrement modifié: il peut être le contexte de compil, et s'interprète alors comme True (ça devrait être transparent). Les instances dans les différents portage ne retourne plus un tableau en cas d'erreur, mais seulement le texte brut de la requête, ça permet
de ne plus dupliquer du code dans les portages.

Il faudrait revoir trace_query, il y a des redondance quant au contexte de compil à présent.

Les fonctions de trace et mesure des requêtes ne sont pas à propremment parler du debug, on sépare les deux jeux de fonctions.

Mettre des appels au débusqueur dans les portages SQL, c'est dupliquer le boulot, mais c'est vrai que c'est pas facile de faire autrement. Voilà déjà une premier déport vers la fonction d'abstraction.

Retour sur [13858] qui n'était pas compatible avec PostGres: si un opérande d'une requête SQL doit être numérique et qu'il est finalement vide, il faut insérer 0 et non pas {{{''}}}. Plutôt que d'alourdir le code généré, on revoit les specs de la fonction {{{sql_quote}}} qui reprenait à tort l'argument concernant les requêtes dans les autres fonctions de l'interface, alors que cette fonction ne fait pas de requêtes. Ce 3e argument inepte contient à présent le type de l'opérande, ce qui permet à cette fonction de forcer une conversion à 0 dans la situation ci-dessus. Etant donné la richesse typologique de PostGres, il est probable que ce nouvel argument serve à nouveau.

Pour Sqlite3, c'était une fausse bonne idée car bien que l'on fasse pointer sur le bon enregistrement, ce n'est pas le résultat de requete d'origine qui est affecté mais un nouveau résultat. L'ancien lui, reste toujours à la même position ce qui ne nous arrange en rien... 

PDO a des limitations dans notre cas : il y a déjà un hack pour calculer le nombre de lignes retournées et ici on ne peut pas faire de seek() ou rewind() [on renvoie false]. Il faudra peut être se diriger vers un autre jeu de fonction pour sqlite3. Peut être http://fr.php.net/sqlite3 ?

- donner à sqlite3 des sql_seek() fonctionnels aussi, mais lui, c'est très tordu, une nouvelle fois à cause des limitations de la classe PDO...

versions pg et sqlite a tester

Dépot obtenu par:

{{{
for i in $(grep  -l '(c) 2001-' * */* */*/* 2> /dev/null)
do
sed 's/(c) 2001-2008/(c) 2001-2009/' $i > /tmp/x
mv /tmp/x $i
done
}}}

- bien faire comprendre à SQLite que "smallint NOT NULL PRIMARY KEY" est autant autoincrement que "smallint (4) NOT NULL PRIMARY KEY".
(merci au plugin géographie pour la découverte du bug)

Retrait du paramètre LIMIT dans la définition de sql_countsel et ses portages. A noter que l'en-tête des fonctions la portant en MySQL, PG et SQLite avaient toutes un paramètre de trop, ce qui rendait en particulier l'argument '''serveur''' inopérant. 

- prise en compte (ignorer) FIRST dans les requetes ALTER
- sql_free() libère la ressource
- auto_increment non conservé dans les requetes create (il semble que cela gène parfois). 
A voir s'il ne faudrait pas systématiquement remplacer un auto_increment par la 
formule unique correcte en SQlite : 'INTEGER NOT NULL PRIMARY KEY'

	- {{{sql_countsel}}} appelé avec un GroupBy X non vide est transformé en COUNT(DISTINCT X); auparavant le résultat était contre-intuitif;

	- {{{sql_getfetsel}}} peut être appelée avec une valeur de Select non réduite à un champ de la table (typiquement un SUM ou un COUNT), l'interface se débrouillera pour construire ce qu'il faut.