Продължавайте да четете,най-добрите опции идват на последно място . Но нека първо изясним няколко неща.
Само заглушаване на заявката за парола
Ако проблемът ви е само в подкана за парола, можете да го заглушите. Цитирам ръководството тук:
-w--no-passwordНикога не издавайте подкана за парола. Ако сървърът изисква удостоверяване с парола и парола не е налична по други средства, като например
.pgpassфайл, опитът за свързване ще бъде неуспешен. Тази опция може да бъде полезна при пакетни задания и скриптове, където няма потребител, който да въведе парола. (...)
Вероятно нямате нужда от парола
Обикновено това е ненужно. Суперпотребител на база данни по подразбиране postgres обикновено съответства на системния потребител със същото име. Изпълнява се psql от този акаунт не изисква парола, ако методът за удостоверяване peer или ident са зададени във вашия pg_hba.conf файл. Вероятно имате ред като този:
local all postgres peer
И обикновено също:
local all all peer
Това означава, всеки местен потребителят може да влезе в всички база данни като потребител на база данни със същото име без парола.
Въпреки това , тук има често срещано погрешно схващане. Отново цитирам:
Този метод се поддържа само при локални връзки .
Удебелен акцент моето.
Вие се свързвате с localhost , коетоне е "локална връзка" , въпреки че в него има думата "местен". Това е TCP/IP връзка към 127.0.0.1. Уикипедия на локален хост:
В съвременните компютърни системи
localhostкато име на хост се превежда в anIPv4 адрес в127.0.0.0/8(loopback) мрежов блок, обикновено127.0.0.1, или::1в IPv6.
Просто решение за локални връзки
Пропуснете параметъра -h от psql призоваване. Цитирам ръководството за psql още веднъж:
Ако пропуснете името на хоста, psql ще се свърже чрез Unix-домейн сокет към сървър на локалния хост или чрез TCP/IP към
localhostна машини, които нямат сокети на Unix домейн.
Windows
... няма сокети на Unix домейн, pg_hba.conf редове, започващи с local не са приложими в Windows. В Windows се свързвате чрез localhost по подразбиране, което ни връща към началото.
Ако изискванията ви за сигурност са слаби, можете просто да се доверите на всички връзки чрез localhost :
host all all 127.0.0.1/32 trust
Бих направил това само за отстраняване на грешки с изключени отдалечени връзки. За по-голяма сигурност можете да използвате SSPI удостоверяване в Windows. Добавете този ред към pg_hba.conf за "локални" връзки:
host all all 127.0.0.1/32 sspi
Ако наистина имате нужда от парола
Вие можете задайте променлива на средата , но това еобезкуражено , особено за Windows. Ръководството:
PGPASSWORDсе държи по същия начин като параметъра за връзка с парола. Използването на тази променлива на средата не се препоръчва от съображения за сигурност, тъй като някои операционни системи позволяват на потребителите без root права да виждат променливите на средата на процеса чрез ps; вместо това помислете за използването на~/.pgpassфайл (вижте раздел 32.15).
Ръководството за psql :
conninfo string е алтернатива за определяне на параметри на връзката:
$ psql "user=myuser password=secret_pw host=localhost port=5432 sslmode=require"
Или URI , което се използва вместо име на база данни:
$ psql postgresql://myuser:example@sqldat.com:5432/mydb?sslmode=require
Файл с парола
Но обикновено е за предпочитане да настроите .pgpass файла вместо да поставяте пароли в скриптови файлове.
Прочетете внимателно кратката глава в ръководството. По-специално, имайте предвид, че тук ...
Име на хост
localhostсъвпада и с двата TCP (име на хостlocalhost) и Unix домейн сокет (pghostпразна или директория на сокет по подразбиране) връзки, идващи от локалната машина.
Точният път зависи от системата. Този файл може да съхранява пароли за множество комбинации от роля и порт (DB клъстер):
localhost:5432:*:myadmin:myadminPasswd
localhost:5434:*:myadmin:myadminPasswd
localhost:5437:*:myadmin:myadminPasswd
...
На Windows машините търсят файла в:
%APPDATA%\postgresql\pgpass.conf
%APPDATA% обикновено се разрешава до:C:\Documents and Settings\My_Windows_User_Name\Application Data\ .