Exécutez le fichier batch avec la commande psql sans mot de passe

Continuez à lire, les meilleures options viennent en dernier . Mais clarifions d'abord quelques points.

Silence uniquement la demande de mot de passe

Si votre problème est uniquement l'invite de mot de passe, vous pouvez la désactiver. Je cite le manuel ici :

-w
--no-password

N'émettez jamais d'invite de mot de passe. Si le serveur requiert une authentification par mot de passe et qu'un mot de passe n'est pas disponible par d'autres moyens tels qu'un .pgpass fichier, la tentative de connexion échouera. Cette option peut être utile dans les travaux par lots et les scripts où aucun utilisateur n'est présent pour entrer un mot de passe. (...)

Vous n'avez probablement pas besoin d'un mot de passe

Normalement, cela n'est pas nécessaire. Le superutilisateur de base de données par défaut postgres correspond généralement à l'utilisateur système du même nom. Exécution de psql de ce compte ne nécessite pas de mot de passe si la méthode d'authentification peer ou ident sont définis dans votre pg_hba.conf dossier. Vous avez probablement une ligne comme celle-ci :

local    all    postgres    peer

Et généralement aussi :

local    all    all         peer

Cela signifie que chaque local l'utilisateur peut se connecter à tous base de données en tant qu'utilisateur de base de données du même nom sans mot de passe.
Cependant , il y a une idée fausse commune ici. Je cite à nouveau :

Cette méthode n'est prise en charge que sur les connexions locales .

Gras gras de la mienne.
Vous vous connectez à localhost , qui n'est pas une "connexion locale" , même s'il contient le mot "local". Il s'agit d'une connexion TCP/IP vers 127.0.0.1. Wikipédia sur localhost :

Sur les systèmes informatiques modernes, localhost car un nom d'hôte se traduit par une adresse IPv4 dans le 127.0.0.0/8 (loopback) net block, généralement 127.0.0.1 , ou ::1 en IPv6.

Solution simple pour les connexions locales

Omettre le paramètre -h depuis le psql invocation. Citant le manuel sur psql une fois de plus :

Si vous omettez le nom d'hôte, psql se connectera via un socket de domaine Unix à un serveur sur l'hôte local, ou via TCP/IP à localhost sur les machines qui n'ont pas de sockets de domaine Unix.

Windows

... n'a pas de sockets de domaine Unix, pg_hba.conf lignes commençant par local ne sont pas applicables sous Windows. Sous Windows, vous vous connectez via localhost par défaut, ce qui nous ramène au début.

Si vos exigences de sécurité sont laxistes, vous pouvez simplement faire confiance à toutes les connexions via localhost :

host    all    all    127.0.0.1/32     trust

Je ne ferais cela que pour le débogage avec les connexions à distance désactivées. Pour plus de sécurité, vous pouvez utiliser l'authentification SSPI sous Windows. Ajoutez cette ligne à pg_hba.conf pour les connexions "locales" :

host    all    all    127.0.0.1/32     sspi

Si vous avez réellement besoin d'un mot de passe

Vous pourriez définir une variable d'environnement , mais cela est déconseillé , en particulier pour Windows. Le manuel :

PGPASSWORD se comporte de la même manière que le paramètre de connexion du mot de passe. L'utilisation de cette variable d'environnement n'est pas recommandée pour des raisons de sécurité, car certains systèmes d'exploitation permettent aux utilisateurs non root de voir les variables d'environnement de processus via ps ; pensez plutôt à utiliser le ~/.pgpass fichier (voir Section 32.15).

Le manuel sur psql :

Un conninfo string est une alternative pour spécifier les paramètres de connexion :

 $ psql "user=myuser password=secret_pw host=localhost port=5432 sslmode=require"

Ou un URI , qui est utilisé à la place d'un nom de base de données :

 $ psql postgresql://myuser:example@sqldat.com:5432/mydb?sslmode=require

Fichier de mot de passe

Mais il est généralement préférable de mettre en place un .pgpass fichier plutôt que de mettre des mots de passe dans des fichiers de script.
Lisez attentivement le court chapitre du manuel. En particulier, notez qu'ici ...

Un nom d'hôte localhost correspond à la fois à TCP (nom d'hôte localhost ) et socket de domaine Unix (pghost vide ou le répertoire de socket par défaut) connexions provenant de la machine locale.

Le chemin exact dépend du système. Ce fichier peut stocker des mots de passe pour plusieurs combinaisons de rôle et de port (cluster DB) :

localhost:5432:*:myadmin:myadminPasswd
localhost:5434:*:myadmin:myadminPasswd
localhost:5437:*:myadmin:myadminPasswd
...

Sous Windows les machines recherchent le fichier dans :

%APPDATA%\postgresql\pgpass.conf

%APPDATA% se résout généralement en :C:\Documents and Settings\My_Windows_User_Name\Application Data\ .