Je ne pense pas que la doc soit assez précise
J'ai trouvé pour l'export qu'il y a psql -c "COPY foo_table TO stdout DELIMITER ',' CSV HEADER" \
    | gzip > foo_table.csv.gz

il me faudrait l'équivalent mais pour l'import

Autant pour moi j'ai mal lu ><. Et avec un overlay(',' placing '.') ou quelque chose dans ce genre ?
Il me semble que dans mes cours sql il y a une autre fonction.

C'est exactement la même table , et il y a un oid , ou plutôt un rowid , d'où le WHERE OID = ROWIDS; car à la base c'était WHERE ROWID = ROWIDS; enfin bref. Je testerai demain si possible avec le contenu total de la base oracle , soit des millions de lignes et je verrais le résultat. En tout cas merci beaucoup pour votre patiente et votre aide.
PS: 72000 insert en 591445ms ( soit 9,8min ) au lieu de ~27min

Justement c'est là où c'est drôle , car il n'y en a pas. Aucune clé primaire , aucune contrainte d'unicité , les tables temporaires sont juste des colonnes qu'on insérera dans la table principale en ajoutant une colonne qui contiendra la clé primaire , donc inutile pour moi à ce stade.
Pour l'index j'ai mis CREATE INDEX I_TMP_ENTCDECLI on TMP_ENTCDECLI(NUM_ETT, NUM_BU, NUM_TYPETT, NUM_CDECLI, DAT_CREPROD,OID).
La fonction vient juste de finir , cela m'a pris 9,5min , sa moins de la moitié du temps initial.

Effectivement le problème vient de l'update , j'ai exécuté ma fonction sans , le résultat est de 1 sec.
Le seul index que j'ai est celui de la fonction qui crée au début et supprimé à la fin.
Pour l'oid il y était de base donc je préfère le laisser au moins pour l'instant , s'il faut faire sans je verrai plus tard si je peux l'enlever.
Et pour le explain j'obtiens:
Merge Join  (cost=44791.38..47440.74 rows=119009 width=139)
   Merge Cond: ((t_ref_ett.cod_typett = tmp_entcdecli.num_typett) AND (t_ref_ett.num_bu = tmp_entcdecli.num_bu) AND (t_ref_ett.num_ett = tmp_entcdecli.num_ett))
   ->  Sort  (cost=17.26..17.74 rows=193 width=39)
         Sort Key: t_ref_ett.cod_typett, t_ref_ett.num_bu, t_ref_ett.num_ett
         ->  Seq Scan on t_ref_ett  (cost=0.00..9.93 rows=193 width=39)
   ->  Sort  (cost=44774.13..45138.59 rows=145787 width=160)
         Sort Key: tmp_entcdecli.num_typett, tmp_entcdecli.num_bu, tmp_entcdecli.num_ett
         ->  Seq Scan on tmp_entcdecli  (cost=0.00..8351.34 rows=145787 width=160)
               Filter: (etat_int <> 1::numeric)

En essayant une autre méthode j'ai remarqué que mon cursor met 20min au moins les 25 pour se créer , et le lire ligne par ligne puis de faire un update à chaque ligne d'une colonne état qui par la suite servira à savoir s'il faut faire un traitement sur cette ligne. Est-ce normal que ce soit aussi long?

J'ai trouvé la table qui me bloque, il s'agit de t_ref_ett , en utilisant la table pg_locks j'obtiens:
          relname           |        mode         | granted |  pid
-----------------------------------+--------------------------+---------+-------
pk_t_entcdecli                       | AccessShareLock        | t          |  6320
pg_class_relname_nsp_index | AccessShareLock         | t          | 13590
t_ref_ett                               | AccessExclusiveLock    | f          | 29689
pk_t_ref_ett                          | AccessShareLock         | t          |  6320
pg_locks                               | AccessShareLock         | t         | 13590
ak_cle_2_t_entcde                 | AccessShareLock        | t          |  6320
pg_class                               | AccessShareLock         | t         | 13590
t_ref_ett                               | AccessShareLock         | f         | 11354
tmp_entcdecli                       | AccessShareLock         | t          |  6320
t_ref_ett                               | AccessShareLock         | t         |  6320
ak_cle_unicite_t_ref_et          | AccessShareLock         | t         |  6320
t_ref_ett                               | AccessExclusiveLock    | f         | 22781
t_ref_ett                               | AccessExclusiveLock    | f         |  9346
t_entcdecli                            | AccessShareLock         | t         |  6320
pg_class_oid_index               | AccessShareLock          | t        | 13590

Je n'ai aucun message d'erreur , au bout de 10min j'ai fais un ctrl - C , pour 1 update je pense que sa fait beaucoup. Oui je l'ai fais , rien d'étrange , je peux faire un delete mais pas de drop , ni utiliser mes fonctions , par contre les autres tables oui.

Oui c'est à peu près sa , en moyenne 25ms pour un insert ; plus rapide pour un update je pense. Mais ma table test contient 100000 lignes , la principale 1M. Je testerai cette méthode plus tard , j'ai quelques problèmes assez contraignant car mes fonctions ne fonctionne plus , du moins je n'ai pas de réponse , même un vacuum full ne se finit pas...

Merci je vais essayer sa , même si sa risque d'être compliqué

Oui mais je ne peux pas faire comme ça. Pour faire de la même façon qu'un bulk collect...limit 1000 est-ce que je pourrais utiliser un curseur avec des tableaux pour mes variables COLUMNS, etc....?

l'id est juste une clé primaire créée lorsque l'on insert une ligne de la table temporaire vers la table principale.