un nouvel utilisateur allemand (Gabor Janak, g.janak@addoma.de) vient de trouver un bug relatif à PostGres. Je traduis approximativement:
Quand on installe SPIP sous PostGres la statistique ne marche pas.
Il y a des fonctions spécifiques à MySQL qu'il contourne avec le code suivant:
CREATE OR REPLACE FUNCTION from_unixtime(integer) RETURNS timestamp AS '
SELECT
$1::abstime::timestamp without time zone AS result
' LANGUAGE 'SQL';
CREATE OR REPLACE FUNCTION unix_timestamp() RETURNS integer AS '
SELECT
ROUND(EXTRACT( EPOCH FROM abstime(now()) ))::int4 AS result;
' LANGUAGE 'SQL';
CREATE OR REPLACE FUNCTION unix_timestamp(timestamp with time zone) RETURNS
integer AS '
SELECT
ROUND(EXTRACT( EPOCH FROM ABSTIME($1) ))::int4 AS result;
' LANGUAGE 'SQL';
Puis il a découvert que pg.php enleve tous les " as *" de la liste OrderBy , ce que lui semble en principe bon.
Il fait remarquer que ce n'est pas correct pour les casts. Il a écrit un bout de code alternatif pour les casts qui survit cette procédure.
Gabor appelle ce code un exemple et se demande si c'est également possible ave MySQL.
un nouvel utilisateur allemand (Gabor Janak, g.janak@addoma.de) vient de trouver un bug relatif à PostGres.
Ah, j'aurais dû me douter que l'intérêt pour SPIP-Postgres susciterait plus d'intérêt en Allemagne qu'en France.
Je traduis approximativement:
Quand on installe SPIP sous PostGres la statistique ne marche pas.
Il y a des fonctions spécifiques à MySQL
Pour from_unixtime, c'est effectivement un oubli que j'avais noté puis ... oublié.
Pour unix_timestamp en revanche, il est substitué avant envoi; pourrait-il indiquer le fichier où ça n'est pas remplacé (ou le squelette si ça vient de l'espace public) ?
Puis il a découvert que pg.php enleve tous les " as *" de la liste OrderBy , ce que lui semble en principe bon.
Il fait remarquer que ce n'est pas correct pour les casts.
Il y a une astuce horrible dans le code qui consiste à écrire AS en majuscule pour un cas et en minuscules pour l'autre afin de les distinguer. Il y aurait nettement mieux à faire et il y a peut-être un bug qui traine, mais ça marche (en théorie). De nouveau pourrait-il localisé le problème ?
Pour finir il pose la question s'il y a des efforts pour développer SPIP dans ce sens.
Je ne comprends pas bien la question: SPIP a maintenant un jeu de fonctions virtuelles porté sur différents serveurs SQL dont PostGres, en théorie il n'y a plus rien à faire. En pratique, ça pourrait être plus efficace et il y a certainement d'autres bugs que ceux qu'il a trouvés, mais c'est toujours pareil: pour qu'on travaille il faut qu'il y ait au moins un utiliateur qui veut bien jouer les testeurs.
Merci Emmanuel, je poste un résumé de ta réponse sur spip-de@rezo.net tout en indiquant qu'il y a également spip-en@rezo.net au cas où Gabor aurait envie de discuter SPIP/Postgres directement avec toi.