Quel est le numéro de ligne indiqué par l'erreur? En particulier est-ce que c'est la ligne 1?

Il est possible de demander du binaire avec un curseur binaire, indépendamment de l'interface côté client:

par exemple:

BEGIN;
DECLARE c binary cursor for select array[1,2]::int[];
FETCH FROM c;   -- le résultat sera en binaire
...
END;

Mais la plupart des interfaces ne savent pas quoi faire avec du binaire.

En C on peut utiliser PQexecParams() et autres fonctions de la même génération qui permettent (sans utiliser de curseur) de demander un résultat en binaire, et aussi de passer des paramètres $1, $2,...  en binaire.
Mais l'interprétation du résultat reste à la charge du programmeur. Chaque type a un encodage binaire spécifique, documenté dans les sources, mais il y a une bibliothèque idéale pour ça: http://libpqtypes.esilo.com/

On voit bien en quoi les plans d'exécution sont différents, mais là le résultat du count(*) semble être zéro.

Comme les plans d'exécution dépendent entre autres des statistiques sur les tables, ça n'a pas trop d'intérêt d'analyser des plans sur des données dont les volumes ne réflètent pas l'environnement de production.

C'est déjà comme ça, il n'y a pas besoin de certificat côté client pour utiliser sslmode=require.

D'ailleurs le mode par défaut sslmode=prefer essaye une connexion TLS en premier et une connexion non chiffrée uniquement si le serveur en face n'est pas configuré pour TLS, si bien que les connexions peuvent être chiffrées sans même avoir rien demandé.

(remarque: TLS et SSL désignent la même chose, TLS c'est le juste le nom moderne).

ce serait du genre

 FROM
n_bdt_bati_indifferencie_s_000 LEFT JOIN n_apr_bati_l_000 
    ON (n_bdt_bati_indifferencie_s_000.id = n_apr_bati_l_000.id_bat)
LEFT JOIN n_apr_adresse_p_000 
    ON (n_apr_adresse_p_000.id = n_apr_bati_l_000.id_adr)

Une présentation sur le sujet qui peut éventuellement aider:

https://fr.slideshare.net/fuzzycz/postg … fs-and-zfs

Pour les perfs, en plus du choix du FS, les options de montage entrent en ligne de compte.

Tout à fait!

Je crois me souvenir qu'Access avec ODBC détermine ça par le fait que les valeurs qu'il relit d'une ligne lors d'une demande de mise à jour ne sont pas les mêmes que celles qu'il a trouvé quand il a l'a lu précédemment.

Donc de son point de vue, un trigger qui change la valeur d'une colonne, c'est "another user".

C'est aussi pour ça que cette erreur peut survenir sur certains de types de données un peu exotiques, pour lesquels parfois Access ne reconnait pas ce que lui-même a mis dans la table après relecture et réinterprétation via la couche ODBC.

PS: il faut bien voir qu'un système d'historisation "soft-delete" qui transforme carrément les DELETE en UPDATE est très intrusif et surprenant pour le côté client. Le fait qu'Access/ODBC soit paumé n'est qu'une conséquence parmi d'autres de cette méthode.
Personnellement je préfère sans hésiter un système qui historise les lignes effacées en les copiant dans d'autres tables, comme mentionné dans une discussion précédente qui concernait vraisemblablement le même projet:
http://forums.postgresql.fr/viewtopic.php?id=4146

Comment voir que telle colonne correspond à telle valeur sans importer? C'est assez facile avec les commandes Unix sed et paste.
1. faire

sed -e 's/,/\n/g'  > entete

et copier coller la ligne d'entête dans le terminal, en entrée standard. Elle va se retrouver dans le fichier entete mais au format une ligne par champ.
2. faire la même chose avec la ligne de données: 

sed -e 's/,/\n/g'  > ligne

3. faire

paste entete ligne

et ça donne ce type de résultat:

Le fait de compter sur le serveur pour couper ces connexions, c'est prendre le problème à l'envers. C'est le client (en l'occurrence le pooler) qui est à l'initiative de l'ouverture de connexion, c'est à lui de savoir quand il n'en a plus besoin et de la fermer.
Même si une connexion est ouverte depuis longtemps et ne fait rien, le serveur ne peut pas deviner si une requête arrivera la milliseconde d'après ou pas.
En principe libérer des connexions inutilisées fait partie des fonctions de base d'un pooler.

Des connexions "idle in transaction" sur de longues durées, c'est problématique, parce qu'en fonction de ce qu'a fait la transaction avant d'arriver à cet état, il est possible que des ressources restent verrouillées, ce qui empêche les autres transactions de progresser. Un problème bien connu est aussi que ça empêche VACUUM de faire son travail.

Les connexions simplement "idle" ne posent pas ce problème. Il est quand même bon de les éliminer si elles ne servent plus, mais ce n'est pas du tout la même criticité.

Il n'y a pas d'impossibilité mais il y a des choix d'organisation à faire en fonction des objectifs.
Dans la description ci-dessus il est difficile de cerner qui produit des données, qui doit les importer, qui les consomme, et quelles sont les données communes ou non communes entre intervenants.

En tout cas une organisation assez classique est d'avoir un seul serveur PostgreSQL (une seule "instance") pour pouvoir mettre en commun les données, et des postes clients multiples. Les postes client n'ont pas de base de données PostgreSQL mais ils ont des applications comme pgAdmin qui se connectent à la base. Ca a l'avantage qu'il y a un seul serveur à administrer, et que les données sont en commun.

Oui ça pose un problème si pgadmin3 ne tourne pas sur la même machine que le serveur postgresql.
Avec COPY le serveur ne reçoit pas le contenu du fichier, il reçoit le chemin du fichier.
Si le chemin du fichier correspond au disque local d'un autre ordinateur, il ne pourra pas l'ouvrir.

Utiliser psql et son \copy résoud ce problème là (dans ce cas c'est les données qui transitent, et non pas le chemin du fichier), et apparemment pgadmin3 n'a pas d'équivalent.

psql permet aussi d'automatiser les traitements, si les fichiers s'appellent toujours pareil il est possible d'appeler ça de manière non interactive avec

psql -f script.sql

. Mais l'environnement console parait hostile à certains utilisateurs, ça dépend des habitudes et s'ils ont plutôt une culture windows/souris ou unix/clavier.