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  (Rich Shepard <rshepard@appl-ecosys.com>)
Список 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 по дате отправления:

Предыдущее
От: Rich Shepard
Дата:
Сообщение: Re: Upgrading using pg_dumpall
Следующее
От: Adrian Klaver
Дата:
Сообщение: Re: Upgrading using pg_dumpall