Kör batchfil med psql-kommandot utan lösenord

Fortsätt läsa, de bästa alternativen kommer sist . Men låt oss förtydliga ett par saker först.

Tysta bara lösenordsbegäran

Om problemet bara är lösenordsuppmaningen kan du tysta det. Jag citerar manualen här:

-w
--no-password

Ge aldrig en lösenordsuppmaning. Om servern kräver lösenordsautentisering och ett lösenord inte är tillgängligt på andra sätt som t.ex. .pgpass fil, kommer anslutningsförsöket att misslyckas. Det här alternativet kan vara användbart i batch-jobb och skript där ingen användare är närvarande för att ange ett lösenord. (...)

Du behöver förmodligen inget lösenord

Normalt är detta onödigt. Standarddatabassuperanvändaren postgres motsvarar vanligtvis systemanvändaren med samma namn. Kör psql från det här kontot kräver inget lösenord om autentiseringsmetoden peer eller ident är inställda i din pg_hba.conf fil. Du har förmodligen en rad så här:

local    all    postgres    peer

Och vanligtvis också:

local    all    all         peer

Det betyder att alla lokala användare kan logga in på en all databas som databasanvändare med samma namn utan lösenord.
Men , det finns en vanlig missuppfattning här. Citerar igen:

Den här metoden stöds endast på lokala anslutningar .

Fet betoning min.
Du ansluter till localhost , som inte är en "lokal anslutning" , även om det har ordet "lokal" i sig. Det är en TCP/IP-anslutning till 127.0.0.1. Wikipedia på localhost:

På moderna datorsystem, localhost som ett värdnamn översätts till en IPv4-adress i 127.0.0.0/8 (loopback) nätblock, vanligtvis 127.0.0.1 , eller ::1 i IPv6.

Enkel lösning för lokala anslutningar

Utelämna parametern -h från psql åkallan. Citerar manualen på psql ännu en gång:

Om du utelämnar värdnamnet ansluter psql via en Unix-domänsocket till en server på den lokala värden, eller via TCP/IP till localhost på maskiner som inte har Unix-domänsockets.

Windows

... har inte Unix-domänsockets, pg_hba.conf rader som börjar med local är inte tillämpliga på Windows. På Windows ansluter du via localhost som standard, vilket för oss tillbaka till början.

Om dina säkerhetskrav är slappa kan du bara lita på alla anslutningar via localhost :

host    all    all    127.0.0.1/32     trust

Jag skulle bara göra det för felsökning med fjärranslutningar avstängda. För lite mer säkerhet kan du använda SSPI-autentisering på Windows. Lägg till den här raden i pg_hba.conf för "lokala" anslutningar:

host    all    all    127.0.0.1/32     sspi

Om du faktiskt behöver ett lösenord

Du kunde ställ in en miljövariabel , men detta är avskräckt , speciellt för Windows. Manualen:

PGPASSWORD fungerar på samma sätt som lösenordsanslutningsparametern. Användning av denna miljövariabel rekommenderas inte av säkerhetsskäl, eftersom vissa operativsystem tillåter icke-rotanvändare att se processmiljövariabler via ps; överväg istället att använda ~/.pgpass fil (se avsnitt 32.15).

Manualen om psql :

En conninfo string är ett alternativ för att ange anslutningsparametrar:

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

Eller en URI , som används istället för ett databasnamn:

 $ psql postgresql://myuser:[email protected]:5432/mydb?sslmode=require

Lösenordsfil

Men det är vanligtvis att föredra att ställa in en .pgpass fil istället för att lägga in lösenord i skriptfiler.
Läs det korta kapitlet i manualen noggrant. Observera särskilt att här ...

Ett värdnamn för localhost matchar både TCP (värdnamn localhost ) och Unix-domänsocket (pghost tomma eller standardsocket-katalogen) anslutningar som kommer från den lokala maskinen.

Exakt väg beror på systemet. Den här filen kan lagra lösenord för flera kombinationer av roll och port (DB-kluster):

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

På Windows maskiner letar efter filen i:

%APPDATA%\postgresql\pgpass.conf

%APPDATA% löser vanligtvis till:C:\Documents and Settings\My_Windows_User_Name\Application Data\ .