Re: Upgrading using pg_dumpall
От | Adrian Klaver |
---|---|
Тема | Re: Upgrading using pg_dumpall |
Дата | |
Msg-id | 11bddea1-b933-048a-a3ef-dcdaf6e953ca@aklaver.com обсуждение исходный текст |
Ответ на | Re: Upgrading using pg_dumpall (Rich Shepard <rshepard@appl-ecosys.com>) |
Ответы |
Re: Upgrading using pg_dumpall
|
Список | pgsql-general |
On 09/04/2016 12:10 PM, Rich Shepard wrote: > On Sun, 4 Sep 2016, Adrian Klaver wrote: > >> You don't it directly. That information is supplied by Postgres when you >> do CREATE or ALTER ROLE. The -W switch just does that for the >> superuser(postgres in your case) when you initdb a new cluster. > > Adrian, > > OK. That makes sense. > >> Sorry, old habits. pg_user is a version of the pg_shadow view that blanks >> out the actual password. pg_shadow is a view over the table pg_authid, >> where the actual information is stored now. In any case, again they are >> not tables/views you directly modify. > > Good. Then I won't spend time with them. > > So, given my single-user situation do you think that I should ALTER ROLE > to add my password? Adding it to ~/.pgpass did nothing positive when I > changed auth method to md5; my attempt to open a database failed because > that password was rejected. Strange ... to me. Another thing that came to mind is compatibility with existing applications/clients. You say you have been running using trust and I am betting your client connection parameters reflect that. Now for connections methods that can 'see' the .pgpass file and use libpq as the their underlying Postgres library then things should work. Otherwise your applications may not be able to connect until you supply the correct password in some manner. > > Rich > > > -- Adrian Klaver adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: