Hello,
j'ai voulu clore les tickets ouverts sur le portage postgreSQL, mais je tombe sur un problème bien plus fondamental qui m'inquiète un peu.
En préambule, j'utilise http://bitnami.org/stack/mappstack comme environnement de test,
avec une version PostgreSQL 9.0.3
Je prends ici l'exemple de la table spip_articles.
Le point de blocage concerne les insertion en base et l'autoincrement.
Actuellement il est obtenu par une valeur par defaut
nextval('spip_articles_id_article_seq'::regclass)
sur id_article
Une requete insertion
sql_insertq('spip_articles',array('titre'=>'toto2')
marche bien, jusque là tout va bien
MAIS
sql_insertq('spip_articles',array('id_article'=>1,'titre'=>'toto2')
echoue elle sur une erreur
errcode: 1000 : currval of sequence "spip_articles_id_article_seq" is not yet defined in this session
De fait, la doc explique que currval n'est pas defini tant qu'on a pas fait un nextval, et comme ici id_article etait defini dans l'insertion,
le defaut ne s'est pas joué.
Donc je produit un patch ci-dessous pour retourner id_article si il est dans les donnees inserees, et currval sur une attribution automatique
Dans ce cas, mes deux insertions ci-dessus marchent bien séparemment.
Problème numéro 1 :
Si je fais
sql_insertq_multi('spip_articles',array(array('id_article'=>1,'titre'=>'toto'),array('id_article'=>2,'titre'=>'toto')));
je recupere le premier id_article, et non le second.. ça peut se contourner, et le retour sur le sql_insertq_multi n'est pas très grave
Mais beaucoup plus gênant :
Problème numéro 2 :
Si je fais plusieurs insertions mixées, nextval/curval n'est pas synchronisé :