Bonjour,
Je ne sais pas si votre sujet est toujours d'actualité mais à mon avis, vous pourriez avoir cela avec dblink : https://docs.postgresql.fr/10/contrib-d … ction.html

Ok merci pour les réponses

Ah je me suis trompé, en revérifiant il avait bien des INSERT INTO RETURNING INTO STRICT dans mon code. J'ai renforcé les conditions (verification de données ) pour entrer dans cette partie de "INSERT INTO" et c'est bon.

Les pistes de rjuju  et gleu : clause INTO STRICT et le numéro de ligne où l'eurreur est rencontré m'ont aidé.

Merci à tous.

Bah en fait, c'est aussi un souci, car tu vois le message d'erreur il n'indique pas la requête qui pose problème. Le message dit juste : ERROR: queyr returned no rows SQL state: P0002 Context: PL/pgSQL function fusion_temp.algo_fusion(bigint,bigint,bigint,text,text,bigint,bigint,bigint,boolean,boolean,integer)

Et sinon, si on lance PG en mode mono utilisateur avec un certain niveau de debug çà dit quoi, le message est peut être un peu plus clair ou c'est le même que dans le log ?
postgres --single -D /path_pgdata/data -d 3 la_base

Ok, le bout de code suspect dans la fonction :
IF ((p_debut_i <= p_debut_j) AND (p_fin_i >= p_fin_j))THEN
            RAISE NOTICE 'debut FUS 3 idtli % deb i % fini % idtlj % debj % finj %',p_id_temp_i,p_debut_i,p_fin_i,p_id_temp_j,p_debut_j,p_fin_j;
                v_date1 := p_debut_j::date;
                v_date2 := p_debut_j::date +1;
               
                RAISE NOTICE 'SELECT id_temp INTO v_id_temp FROM t_temp WHERE pers = % AND proj = % AND id_op = % AND deb > % AND deb < % AND id_temp <> % AND duree > 0 LIMIT 1',p_pers_j,p_pers_j,p_op_j,v_date1,v_date2,p_id_temp_j;
                --C'EST ICI LE CODE SUSPECT QUI PETE
                SELECT id_temp INTO v_id_temp FROM t_temp WHERE pers = p_pers_j AND proj = p_proj_j AND id_op = p_op_j AND deb > v_date1 AND deb < v_date2 AND id_temp <> p_id_temp_j AND duree > 0 LIMIT 1;
                -- Pour certaine données l'execution de la fonction s'arrete ici et renvoie l'erreur ERROR :  query returned no rows                
                raise notice 'v_id_temp %',v_id_temp;
                IF (v_id_temp is not null) THEN
                    p_qte_j := COALESCE(p_qte_j,0);
                    EXECUTE 'UPDATE '||v_tfusion_temp_i||' SET qte = qte + '||p_qte_j||' WHERE id_temp = '||v_id_temp;
                    EXECUTE 'UPDATE t_temp SET qte = coalesce(qte,0) + '||p_qte_j||', com=''fusion temp: rajout qte du temp '||p_id_temp_j||' algo fus'' WHERE id_temp = '||v_id_temp;
                    PERFORM fusion_temp.update_quantity3(p_proj_j, p_op_j, p_id_temp_j, v_id_temp);
                   
                END IF;
               
                EXECUTE 'DELETE FROM '||v_tfusion_temp_j||' WHERE id_temp = '||p_id_temp_j;
                PERFORM fusion_temp.update_quantity_unicite(p_proj_j, p_op_j, p_id_temp_j, null::integer, null::integer, 'delete'::text);
                PERFORM fusion_temp.delete_temp(p_id_temp_j,p_id_temp_i,'algo fus');
                INSERT INTO fusion_temp.algo_debug(idtli,debi,fini,id_sysi,idtlj,debj,finj,id_sysj,login,algo_trouve,date_recherche) VALUES (p_id_temp_i,p_debut_i,p_fin_i,p_id_sys_i,p_id_temp_j,p_debut_j,p_fin_j,p_id_sys_j,p_pers_i,'algo fus',p_debut_i::date);
                RAISE NOTICE 'fin FUS 3 idtli % deb i % fini % idtlj % debj % finj %',p_id_temp_i,p_debut_i,p_fin_i,p_id_temp_j,p_debut_j,p_fin_j;
                RETURN 3;

rjuju> Si je comprend INSENSITIVE explique le fait que la mise à jour dans la boucle n'est pas perceptible durant la boucle (dans les prochaines itérations) ?
Et WHERE CURRENT OF cursor_name met à jour la ligne sur laquelle le curseur pointe, mais cette modification ne sera pas évaluer à la prochaine itération puisque le curseur est INSENSITIVE  ?
C'est çà ?

Oui c'est çà, la modification n'est pas ré évaluer dans la suite des itérations.
Voilà pourquoi jai du passer par un traçage pour faire connaitre au boucle les changements de valeurs.
Mais est ce que ce principe de traitement de boucle for avec un select est valable pour tout sgbd ?

Pour ajouter je veux que les modifications faites dans la 2ème boucle, soient perceptible au niveau de la 1ère boucle :
itération i=1 de la première boucle , on fait une modification dans la 2ème boucle, donc dans la 2ième itération (et plus) de la première boucle le update fait (dans 2ème boucle) lors de la première itération (1ère boucle) soit pris en compte (valeur mise à jour dans les itérations qui suivent)

Normalement çà devrait être çà non ?