En principe ça ne peut pas arriver avec les commandes indiquées parce que
- pg_dumpall place un \connect nomdelabase dans le script avant les ordres de restauration de cette base
- et psql -f all.sql quitte immédiatement si ce \connect échoue

donc comment ça pourrait restaurer dans la mauvaise base?

A contrario c'est une erreur classique de restaurer un dump individuel (pas pg_dumpall) dans la base postgres parce qu'on a oublié un -d à psql, personnellement ça m'est arrivé plus d'une fois.

C'est l'IP du point de vue de l'extérieur, autrement dit du reste de l'Internet. "Operation timed out" dans la tentative de connexion signifie généralement qu'il y a un firewall qui bloque les paquets, ce qui est normal pour éviter que n'importe qui sur Internet soit tenté de se connecter à votre instance Postgres.

Je pense que cette IP ne sert pas pour ce que voulez faire. Ce que vous voulez, c'est que le container puisse initier une connexion TCP vers le host sur son port 5433. Il y a sûrement moyen de faire ça, mais c'est une question purement réseau docker à laquelle personnellement je ne sais pas répondre.

CentOS 6 fournit en paquet php 5.3, qui n'est plus supporté depuis 2014, cf http://php.net/eol.php (alors que Cent OS 6 est supporté jusqu'en 2020).

Si vous avez compilé vous-même php 7.0.33 pour avoir une version récente, il faut effectivement faire la même chose avec les extensions comme pdo. Mais il n'y a pas besoin de télécharger des sources à part, parce que pdo_pgsql fait déjà partie du code source de php dans le répertoire ext/.  pg_config et les autres dépendances nécessaires devraient être installables via un paquet CentOS postgresql-devel.

Si au contraire vous avez installé php 7.0.33 précompilé via un paquet, il faut voir si le fournisseur de ce paquet ne fournit pas aussi pdo_pgsql et autres extensions, puisque logiquement il devrait.

Effectivement il faudrait mettre un analyseur lexical alternatif, sans quoi dans  "C++" par exemple les + produisent le même lexème qu'un espace:

Il est possible de faire une configuration texte avec son propre analyseur lexical, mais il faut l'écrire en C.
Un exemple ici: https://github.com/postgrespro/pg_tsparser

Pour la partie qui se trouve ici: https://docs.postgresql.fr/10/tutorial-sql.html il n'est pas vraiment nécessaire que make passe dans le répertoire src/tutorial, il suffit de copier dans ce répertoire le fichier basics.source sous le nom basics.sql, ou de ne même pas le copier, et quand la doc dit de faire \i basics.sql, faire \i basics.source à la place.

Quoiqu'il en soit ce tuto est hyper basique, c'est vraiment pour se faire une idée très générale de ce à quoi ressemblent les commandes SQL les plus courantes. Vous irez beaucoup plus loin avec un livre.

Il y a un risque de confusion dans ce que vous faites, parce que vous jouez sur 2 tableaux: la compilation des sources d'un côté, qui est faisable complètement indépendamment des paquets précompilés, et de l'autre côté l'installation des paquets précompilés pour Fedora.

Le Makefile du répertoire tutorial a ces explications en tête de fichier:

Donc après avoir compilé les sources de postgresql, c'est-à-dire essentiellement
1) téléchargé les sources
2) fait un ./configure avec succès à la racine de ces sources
3) fait un make qui s'est terminé aussi avec succès toujours à la racine

On peut aller dans src/tutorial, et lancer:

 make NO_PGXS=1 all

et ça va compiler avec succès le tutoriel.

Cette démarche est dans la logique que les sources sont auto-suffisantes. Ca ne veut pas dire que vous ne devez pas aussi installer postgresql-devel ou d'autres paquets pour ce que vous voulez faire par ailleurs, mais il y a une séparation nette entre ce qui est nécessaire pour compiler PostgreSQL et ce qui est nécessaire pour compiler votre propre projet lié à PostgreSQL sous Fedora.

Non, plpgsql ne sait pas faire ça, pas plus que sql.
Au mieux, les fonctions telles que row_to_json() permettent de lire des jeux de résultats de manière un peu dynamique du fait du modèle collection/clef/valeur du type json,
Mais pour aller vraiment plus loin il faut passer aux langages où les noms de colonnes ne sont pas des identifiants mais des variables.

Ca peut se faire en passant par des fonctions json et une jointure latérale.
Voir "Comment dé-pivoter un jeu de données?" dans
https://blog-postgresql.verite.pro/2018 … pivot.html
pour un exemple concret.

C'est manifestement du format 'escape', c'est-à-dire que les caractères ASCII sont tels quels et les autres sont sous forme octale précédé d'un antislash. \012  est le code de LF en octal.

https://www.postgresql.org/docs/current … inary.html

En ce qui concerne le chargement "bloquant" c'est un point intéressant, parce qu'effectivement laisser l'utilisateur poireauter devant l'écran sans information sur ce qui se passe,  à partir de quelques secondes, c'est vraiment gênant.

L'idéal c'est d'avoir une API et un stockage qui segmente les données et les renvoie segment par segment. Ce que les large objects font nativement, mais ils ont quelques inconvénients,notamment le fait que les segments sont trop petits (2048 octets max) de nos jours et qu'ils ne sont pas prévus pour des opérations en masse sur plein d'objets dans la même transaction (problème de verrouillage).

Mais une table de ce genre:
CREATE TABLE contenu_binaire(numero_objet bigint references objet(numero), numero_segment int, contenu_segment bytea),
qui ressemble beaucoup à pg_largeobject d'ailleurs, mais dont les segments sont limités à 512 Ko permet d'éviter les problèmes liés à la fois à taille des binaires et à leur nombre.

Avec des fichiers externes ça pourrait être fait aussi mais ça demande de la programmation côté serveur avec un langage "untrusted".

Il n'est pas indispensable d'être connecté en tant que super-utilisateur si un super-utilisateur a délégué le droit d'usage via une fonction déclarée avec SECURITY DEFINER.

C'est d'ailleurs ce mécanisme qu'utilise l'extension external_file. Regardez le source:

https://github.com/darold/external_file … e--1.0.sql

CREATE OR REPLACE FUNCTION writeEfile(buffer bytea, e_file efile)
  RETURNS void
AS $$
   etc...
END;
$$ LANGUAGE PLPGSQL SECURITY DEFINER SET search_path = @extschema@, pg_temp;

Quand un super-utilisateur créé cette fonction, cette clause dit que les utilisateurs de cette fonction
auront les droits de super-utilisateur pendant son exécution.

Reste à donner les droits d'exécution via GRANT aux bons rôles, et (très important pour la sécurité), retirer le droit au pseudo-rôle public si ce n'est pas déjà fait globalement (ce pseudo-rôle désigne l'ensemble des utilisateurs):

REVOKE EXECUTE ON FUNCTION nom_de_fonction() FROM public;

J'ai regardé un peu external_file, et c'est du plpgsql, il n'y a pas de code C.

Il utilise les large objects comme stockage intermédiaire, malheureusement ça n'est pas économe en accès disques: stockage du bytea en large object, export du large object en fichier externe, effacement du large object.

Une méthode plus efficace serait de faire des fonctions write_bytea() et read_bytea() qui feraient du transfert fichier<->bytea et rien d'autre, mais là effectivement cette efficacité là suppose de l'écrire en C, donc de compiler. En revanche le contenu lui-même des fonctions serait vraiment simple. C'est comparable à ce que fait pg_read_binary_file() pour la lecture
(une fonction intégrée) et pg_file_write du  module adminpack pour la lecture.

On peut aussi utiliser un langage de script untrusted, mais l'efficacité reste à tester. plperlu par exemple ne gère pas les passages de paramètres en binaire, donc une donnée  de X octets va être transformée en 2*X octets de texte en hexa puis reconvertis à l'envers une fois  dans la fonction.

C'est-à-dire qu'aucun message d'erreur ne s'affiche?

Au pire aller sur le serveur dans le sous-répertoire pg_log à l'intérieur du répertoire postgres,
ou dans l'observateur d'évènements windows suivant la configuration, pour consulter les messages
d'erreurs.