Postgres psql est un client en ligne de commande du serveur PostgreSQL. Il permet de se connecter au serveur de bases de données en local sur la machine serveur ou à distance depuis une autre machine. Une fois connecté, l’utilisateur autorisé peut exécuter des commandes spécifiques à psql qui retournent différentes informations utiles ou exécuter des requêtes SQL. A ce titre il constitue un outil léger et performant pouvant rendre de nombreux services au cours d’un développement qui utilise ce serveur de bases de données. Dans ce tutoriel le login de l’utilisateur authentifié sur la machine est supposé être jdupond. Pour exécuter les commandes des exemples, remplacer toujours ce login par le votre.

Cet article fait partie d’une série qui concerne le serveur de bases de données PostgreSQL et son utilisation dans un environnement de développement:

1. Installation de base de PostgreSQL
2. Utiliser Postgres pgAdmin 3 pour administrer PostgreSQL
3. Installer PostgreSQL 10
4. Reconfigurer l’installation par défaut de PostgreSQL 10
5. Utiliser PostgreSQL 10 dans un environnement de développement
6. Cet article: Administrer PostgreSQL avec psql
7. Postgres pgAdmin 4 : installation et configuration
8. Postgres pgAdmin 4: Utilisation courante

1. Connexion au serveur de BDD avec Postgres psql

La commande de connexion est de la forme suivante:

psql -h <AdresseServeur> -p <Port> -U <UtilisateurBDD> -d <BaseDeDonnees>

Aucun des 4 paramètres n’est obligatoire. Quand l’un de ces paramètres n’est pas fourni, sa valeur par défaut est prise en compte:

Paramètre	Contenu	Valeur par défaut
h	Adresse de la machine serveur de base de données	Connexion en local par le socket Unix
p	Port de connexion sur la machine serveur	5432
U	Utilisateur de base de données	login de l’utilisateur qui exécute la commande
d	Base de données	login de l’utilisateur qui exécute la commande

A titre de test, exécuter:

psql

La commande échoue, le message d’erreur indique qu’il n’y a pas de BDD qui a pour nom le login. Si on exécute:

psql -d postgres

La connexion réussit dans le cas d’un cluster personnalisé pour l’utilisateur authentifié.

Pour se connecter en tant que utappli sur la BDD bdappli:

psql -h localhost -U utappli -d bdappli

La commande demande le mot de passe car utappli est soumis à ce type d’authentification, puis réussit.

2. Postgres psql peut se souvenir de la BDD par défaut et des mots de passe

Il existe deux paramétrages possibles qui permettent de simplifier la commande de connexion.

• Modifier la BDD à utiliser par défaut.

Pour cela créer le fichier .postgresqlrc comme suit:

vi /home/jdupond/.postgresqlrc

Son contenu doit être:

10  pgtest  bdappli

Exécuter après avoir enregistré:

psql

La connexion réussit. La BDD à laquelle on se connecte est bdappli qui remplace, par défaut, le login de l’utilisateur.

• Se souvenir du mot de passe de l’utilisateur de connexion

Pour se connecter en tant que utappli, psql demande de saisir le mot de passe à chaque fois. Ce comportement peut être modifié en renseignant le mot de passe dans le fichier /home/jdupond/.pgpass

Créer ce fichier avec le contenu (mputappli est le mot de passe de utappli):

localhost:5432:*:utappli:mputappli

Ce nouveau fichier contenant un mot de passe, il faut le sécuriser:

chmod 600 /home/jdupond/.pgpass

Exécuter ensuite:

psql -h localhost -U utappli -d bdappli

La connexion réussit sans demander le mot de passe de l’utilisateur.

3. Utiliser les commandes de Postgres psql

En plus de la capacité d’exécuter des requêtes SQL, l’utilitaire psql fournit un ensemble de commandes utiles pour l’exploitation du serveur.

Etant connecté au serveur PostgreSQL, à la base de données bdappli, avec l’utilitaire psql, on va tester un certain nombre de ces commandes. Exécuter l’une de ces commandes revient à la saisir et ensuite utiliser la touche entrée du clavier.

\?

Permet d’afficher la liste complète des commandes psql avec une description de leurs fonctions. Remarquer que ces commandes commencent toujours par le caractère backslash (\).

\h select

Fournit une explication complète de la syntaxe de la commande SQL select. La commande psql \h est un aide mémoire précieux du langage SQL.

\l

Affiche la liste des bases de données du serveur.

\dn

Permet de voir la liste des schémas de la base de données active.

\d commerce.*

Affiche les informations à propos de toutes les tables du schéma commerce. Remarquer la table créée automatiquement pour gérer la séquence du champ id

\d commerce.produits

Affiche les informations à propos de la table produits du schéma commerce.

4. Echanger les données avec des fichiers grâce à Postgres psql

Créer le fichier /home/jdupond/produits.csv avec le contenu:

CU;clé usb 500 Go
EC;ecran 26 pouces
SR;souris 3 boutons
CA;clavier azerty

Se connecter à la base de données bdappli et exécuter les deux requêtes l’une après l’autre:

copy commerce.produits(code,nom) from '/home/jdupond/produits.csv' (format csv, delimiter ';', header, encoding 'utf8');
select * from commerce.produits;

Comme le montre le résultat de la deuxième requête, le contenu du fichier a été transféré dans la table de la base de données.

Exécuter maintenant:

copy commerce.produits to '/home/jdupond/extraction_produits.csv' (format csv, delimiter ';', header, encoding 'utf8');

Le contenu entier de la table est transféré dans le fichier indiqué et au format indiqué.

Le contenu transféré peut être partiel, selon une condition, en utilisant une requête SQL:

copy (select * from commerce.produits where id=1 or id=2) to '/home/ameddeb/dvlp/travaux/pgdoc/extractionl_produits.csv' (format csv, delimiter ';', header, encoding 'utf8');

Seulement les deux enregistrements demandés ont été transférés.

5. Exécuter une requête SQL depuis le shell système

Postgres psql permet d’exécuter une requête SQL sans se connecter préalablement au serveur. Depuis le shell, exécuter:

psql -c "select * from commerce.produit;"

Le résultat est affiché sur la console.

6. Exécuter un script SQL depuis un fichier

Créeer le fichier /home/jdupond/cree_prix.sql avec le contenu:

create table commerce.prix(id serial, produitid int, prixachat numeric(7,2), prixvente numeric(7,2));
insert into commerce.prix(produitid, prixachat, prixvente) values(1, 6.2, 7.35);
insert into commerce.prix(produitid, prixachat, prixvente) values(2, 230.5, 274.75);

Ensuite exécuter depuis le shell système:

psql -f /home/jdupond/cree_prix.sql
psql -c "select * from commerce.prix;"

Le script s’exécute, crée la table et y insère deux enregistrements. Le résultat de la requête exécutée après le script le confirme.

Le serveur de bases de données PostgreSQL est installé. Cette installation a été reconfigurée pour créer un cluster personnalisé pour l’utilisateur – développeur authentifié sur la machine de bureau. Ces sujets ont été abordés dans des articles précédents. Dans cet article on verra les aspects les plus importants de l’utilisation de ce serveur pour le développement d’applications logicielles qui l’utilisent.

Cet article fait partie d’une série qui concerne le serveur de bases de données PostgreSQL et son utilisation dans un environnement de développement:

1. Installation de base de PostgreSQL
2. Utiliser Postgres pgAdmin 3 pour administrer PostgreSQL
3. Installer PostgreSQL 10
4. Reconfigurer l’installation par défaut de PostgreSQL 10
5. Cet article: Utiliser PostgreSQL 10 dans un environnement de développement
6. Administrer PostgreSQL avec psql
7. Postgres pgAdmin 4 : installation et configuration
8. Postgres pgAdmin 4: Utilisation courante

 Créer un utilisateur de base de données standard

Il est fortement conseillé, même dans un environnement de test/développement, de ne pas utiliser le super administrateur pour une utilisation courante. Pour cela la première chose à faire après l’installation du serveur est de créer un utilisateur standard.

Se connecter au serveur en tant que super administrateur:

psql -d postgres

Une fois connecté, exécuter:

create user utappli with login encrypted password 'mputappli';

Ensuite vérifier la création effective de cet utilisateur:

select * from pg_roles where rolname='utappli';

Enfin quitter psql

\q

Pour tester la connexion de l’utilisateur utappli, exécuter:

psql -h localhost -d postgres -U utappli

Fournir le mot de passe paramétré: mputappli, quand il sera réclamé. 

Cet utilisateur et son mot de passe peuvent être utilisés par l’application en développement pour se connecter au serveur.

Créer une base de données

Pour stocker les données de l’application en développement, il y a un besoin de créer une base de données. Pour cela se connecter en tant que super administrateur et exécuter la requête de création d’une base de données dont le propriétaire est utappli:

psql -d postgres
create database bdappli owner utappli;
\q

Créer les tables de données

L’utilisateur utappli étant le propriétaire de la base de données bdappli, il a tous les droits sur cet objet. Par conséquent, on n’a plus besoin de se connecter en tant que super administrateur. Pour créer une table dans la base de donnée qui vient d’être créée, il faut se connecter à cette base de données en tant que utappli et exécuter les requêtes:

psql -h localhost -U utappli -d bdappli
create schema commerce;
create table commerce.produits (id serial, code varchar(12), nom varchar(100));
select * from commerce.produits;

La dernière requête SQL exécutée permet de vérifier la création effective de la table. Au cours du développement cette requête permettra de vérifier le contenu géré par le code de l’application. Bien entendu d’autres tables ou schémas peuvent être créés de la même manière.

Se connecter au serveur à partir d’une autre machine

Par défaut, la configuration du serveur ne permet que des connexions à partir de la même machine. Cela peut convenir pour un utilisateur-développeur qui utilise seul son serveur. Si une autre personne, qui utilise donc une autre machine, souhaite utiliser les données de ce serveur elle ne pourra pas. Ce comportement peut être changé par la modification de deux fichiers de configuration.

Editer pg_hba.conf:

vi /etc/postgresql/10/pgtest/pg_hba.conf

Ajouter la ligne suivante:

host    all     all    0.0.0.0/0     md5

Editer postgresql.conf:

vi /etc/postgresql/10/pgtest/postresql.conf

Repérer la ligne:

#listen_addresses = 'localhost'

Modifier cette ligne, en (enlever le # et remplacer localhost par *):

listen_addresses = '*'

Pour tenir compte de ces modifications, redémarrer le serveur:

pg_ctlcluster 10 pgtest restart

Pour se connecter, la personne distante, doit utiliser la même commande que pour la connexion locale sauf pour le paramètre -h (host):

psql -h xxx.xxx.xxx.xxx -U utappli -d bdappli

xxx.xxx.xxx.xxx est l’adresse IP de la machine serveur de base de données, par exemple 192.168.0.1. Pour trouver cette adresse IP, exécuter sur cette machine:

sudo ifconfig

Repérer dans la réponse l’adresse qui est mentionnée par le libellé inet. Si cela vous semble compliqué, exécuter:

sudo ifconfig | sed "s/^[ ]*//g" | egrep ^inet | egrep -v "(^inet6|127.0.0.1)" | awk '{ print $2 }'

Cette commande doit afficher une seule adresse IP, utilisez la. Si elle affiche plusieurs, c’est que la machine est connectée à plusieurs réseaux (filaire et wifi par exemple). Dans ce cas toutes ces adresses peuvent être utilisées si la machine de connexion est également connectée au même réseau.

Contrôler les requêtes SQL exécutées par l’application

Il est très utile de pouvoir contrôler les requêtes SQL exécutées par le code de l’application en développement, afin de les affiner. Cette faculté de contrôle est plus nécessaire encore s’il s’agit d’une application de type JEE qui s’exécute dans un serveur d’application.

Par défaut le serveur PostgreSQL n’inscrit pas dans son fichier de log le texte de ces requêtes. Ce comportement est modifiable par le fichier postgresql.conf. Editer ce fichier et repérer la ligne qui commence par:

#log_statement = 'none'

Modifier cette ligne, en (enlever # et remplacer none par all):

log_statement = 'all'

Pour la prise en compte, recharger les fichiers de configuration par la commande:

pg_ctlcluster 10 pgtest reload

A partir de ce moment, le serveur inscrit dans son fichier de log toutes les requêtes exécutées. Pour tester ce comportement, se connecter et exécuter une requête quelconque:

psql -d postgres
select * from pg_roles;
\q

Ensuite vérifier:

cat ~/pgtest.log

La requête qui vient d’être exécutée doit apparaître à la fin de ce fichier.

 

Dans cet article nous reconfigurerons le serveur de base de données PostgreSQL version 10 après une installation faite lors du précédent article. Cette reconfiguration consiste essentiellement en le remplacement du cluster de bases de données installé par défaut. L’objectif est d’obtenir une installation qui convient pour une utilisation dans un environnement de développement sur une machine de bureau.

Cet article fait partie d’une série qui concerne le serveur de bases de données PostgreSQL et son utilisation dans un environnement de développement:

1. Installation de base de PostgreSQL
2. Utiliser Postgres pgAdmin 3 pour administrer PostgreSQL
3. Installer PostgreSQL 10
4. Cet article: Reconfigurer l’installation par défaut de PostgreSQL 10
5. Utiliser PostgreSQL 10 dans un environnement de développement
6. Administrer PostgreSQL avec psql
7. Postgres pgAdmin 4 : installation et configuration
8. Postgres pgAdmin 4: Utilisation courante

L’installation par défaut ne convient pas pour un environnement de développement

La première installation de PostgreSQL crée un utilisateur système: postgres. Le cluster créé lors de cette installation appartient à cet utilisateur: fichiers et droits système. Un utilisateur de base de données (BDD) de même nom: postgres, est également créé. Cet utilisateur est le super administrateur du cluster. Un accés local au serveur de base de données est configuré pour l’utilisateur système postgres. Cet accés local permet à postgres de se connecter au serveur sans authentification supplémentaire en tant qu’utilisateur BDD postgres.

Ce comportement convient à une installation sur un serveur réel. En revanche, il rend contraignant son utilisation sur une machine de développement. Le contrôle du fonctionnement du serveur, la modification de la configuration et l’accès local au serveur doivent se faire en passant par l’utilisateur système postgres. Pour une gestion plus simple du serveur, la meilleure solution est de substituer le login de l’utilisateur-développeur à postgres.

Supprimer le cluster PostgreSQL installé par défaut

Il faut arrêter le serveur s’il est démarré et supprimer le cluster créé par défaut: main. Pour cela exécuter:

sudo pg_dropcluster --stop 10 main

Créer un cluster PostgreSQL personnalisé

Si le login du développeur sur sa machine est jdupond (Pour Jean Dupond), le système lui attribue systématiquement un groupe système jdupond et un répertoire personnel: /home/jdupond. Dans /home/jdupond tout est permis pour l’utilisateur. Ceci nous amène à exécuter la commande suivante pour créer le cluster:

sudo pg_createcluster -u jdupond -g jdupond --locale=fr_FR.UTF-8 -l /home/jdupond/pgtest.log -d /home/jdupond/pgtest 10 pgtest

Cela veut dire, créer le cluster pgtest avec les paramètres:

• Le propriétaire (fichiers, droits et utilisateur BDD d’administration) est jdupond
• La locale qui détermine le format des données et le mode de recherche est le français de France avec encodage unicode UTF-8.
• Le fichier de log qui est très utile pour le développement parcequ’il permet de visualiser les requêtes SQL exécutées par l’application est /home/jdupond/pgtest.log
• Les données sont dans /home/jdupond/pgtest/ ce qui permet leur manipulation directe par l’utilisateur-développeur.

Contrôle du serveur de base de données PostgreSQL

Avec le cluster personnalisé le contrôle du serveur PostgreSQL devient faisable directement par l’utilisateur authentifié. Voici les commandes principales de contrôle avec, en commentaire (après le caractère #), la signification

pg_ctlcluster 10 pgtest start # démarrage
pg_ctlcluster 10 pgtest stop  # arrêt
pg_ctlcluster 10 pgtest status # affichage du statut marche/arrêt
pg_ctlcluster 10 pgtest reload # recharger la configuration
pg_ctlcluster 10 pgtest restart # redémarrer le serveur

Le contrôle inclu même la suppression de ce cluster. Pour cela exécuter:

pg_dropcluster --stop 10 pgtest

Faire attention, toutefois, car la suppression du cluster entraîne la suppression définitive des données qu’il gère.

Gérer les données avec l’utilitaire psql

L’utilitaire en ligne de commande psql est un client de connexion au serveur PostgreSQL. Entre autres choses, il permet à un utilisateur authentifié sur la machine serveur de se connecter à travers le socket Unix du serveur PostgreSQL sans authentification supplémentaire. La connexion se fait avec la commande du shell:

psql -d <NomDeBaseDeDonnees> 

Avec le cluster personnalisé pour jdupond, le super administrateur des bases de données est jdupond. Il peut se connecter en local à la BDD postgres créée par défaut:

psql -d postgres

Une fois connecté, on peut vérifier le statut de super administrateur de jdupond. Pour cela exécuter:

select rolname, rolsuper from pg_roles;

Le résultat de cette requête doit montrer un ‘t‘ (true) pour jdupond dans le champ rolsuper. Le champ rolsuper est un indicateur pour le profile super administrateur. On remarquera également l’absence de l’utilisateur postgres de la liste.

De la même manière il est possible à l’utilisateur-développeur, en exécutant des requêtes SQL, de créer, consulter, modifier ou supprimer tout type d’objets de bases de données: utilisateurs, bases de données, schémas, tables..