Lists: | pgsql-hackers |
---|
From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
---|---|
To: | <bruce(at)momjian(dot)us>,<tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <robertmhaas(at)gmail(dot)com>,<pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Fix for pg_upgrade user flag |
Date: | 2011-05-07 19:43:40 |
Message-ID: | 4DC55A9C020000250003D3DC@gw.wicourts.gov |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
> Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian writes:
>>> One question I have is why we even bother to allow the database
>>> username to be specified? Shouldn't we just hard-code that to
>>> 'postgres'?
>>
>> Only if you want to render pg_upgrade unusable by a significant
>> fraction of people. "postgres" is not the hard wired name of the
>> bootstrap superuser.
>
> I was really wondering if I should be using that hard-coded name,
> rather than allowing the user to supply it. They have to compile in
> a different name, and I assume that name is accessible somewhere.
At home, on my ubuntu machine, I built and ran initdb without
specifying a superuser. It used my OS login of "kevin". Then,
test=# \du
List of roles
Role name | Attributes | Member
of
-----------+------------------------------------------------+--------
---
kevin | Superuser, Create role, Create DB, Replication | {}
test=# create user xxx superuser;
CREATE ROLE
test=# \c test xxx
You are now connected to database "test" as user "xxx".
test=# alter user kevin rename to yyy;
ALTER ROLE
test=# \du
List of roles
Role name | Attributes | Member
of
-----------+------------------------------------------------+--------
---
xxx | Superuser, Replication | {}
yyy | Superuser, Create role, Create DB, Replication | {}
If I run pg_upgrade now, what will it pick? How?
-Kevin
From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us, robertmhaas(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Fix for pg_upgrade user flag |
Date: | 2011-05-07 22:46:29 |
Message-ID: | 201105072246.p47MkTk09157@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Kevin Grittner wrote:
> > Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Bruce Momjian writes:
> >>> One question I have is why we even bother to allow the database
> >>> username to be specified? Shouldn't we just hard-code that to
> >>> 'postgres'?
> >>
> >> Only if you want to render pg_upgrade unusable by a significant
> >> fraction of people. "postgres" is not the hard wired name of the
> >> bootstrap superuser.
> >
> > I was really wondering if I should be using that hard-coded name,
> > rather than allowing the user to supply it. They have to compile in
> > a different name, and I assume that name is accessible somewhere.
>
> At home, on my ubuntu machine, I built and ran initdb without
> specifying a superuser. It used my OS login of "kevin". Then,
>
> test=# \du
> List of roles
> Role name | Attributes | Member
> of
> -----------+------------------------------------------------+--------
> ---
> kevin | Superuser, Create role, Create DB, Replication | {}
>
> test=# create user xxx superuser;
> CREATE ROLE
> test=# \c test xxx
> You are now connected to database "test" as user "xxx".
> test=# alter user kevin rename to yyy;
> ALTER ROLE
> test=# \du
> List of roles
> Role name | Attributes | Member
> of
> -----------+------------------------------------------------+--------
> ---
> xxx | Superuser, Replication | {}
> yyy | Superuser, Create role, Create DB, Replication | {}
>
> If I run pg_upgrade now, what will it pick? How?
Good point --- you would need the user flag in pg_upgrade. Thanks.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +