Re: [PATCHES] Merge pg_shadow && pg_group -- UNTESTED

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: [PATCHES] Merge pg_shadow && pg_group -- UNTESTED
Дата
Msg-id 20050123164025.GQ10437@ns.snowman.net
обсуждение исходный текст
Ответ на Re: [PATCHES] Merge pg_shadow && pg_group -- UNTESTED  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [PATCHES] Merge pg_shadow && pg_group -- UNTESTED  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> >   Here's a proof-of-concept pretty much untested (it compiles) patch
> >   against HEAD for review of the general approach I'm taking to
> >   merging pg_shadow and pg_group.  This is in order to support group
> >   ownership and eventually roles.  This patch includes my grammar and
> >   get_grosysid move patches, and so conflicts with them.
>
> One point is that you can't simply whack pg_shadow around and eliminate
> pg_group, because that will break lord-knows-how-much client software
> that looks at these tables.  What I'm envisioning is to create a new
> system catalog (say pg_role) that holds the New Truth, and then make
> pg_shadow and pg_group be predefined views on this catalog that provide
> as much backwards compatibility as we can manage.

Ok.  Can I get some help defining what the New Truth will look like
then?  I understand users and groups pretty well but I'm not 100% sure
about roles.  Is it as simple as what my changed pg_shadow looks like?
What's the difference between a role, a user and a group?  Can a role
log in/have a password?  Can a role own an object?  If a role owns an
object, can any users who have that role {drop, create index, etc} it?

Once we get the layout of pg_role defined I think I'll be able to make
much better progress towards what you're looking for. :)

> A related point is that I hope soon to get rid of type AclId and
> usesysid/grosysid/rolesysid and start identifying roles by Oids.

Alright.  That doesn't sound too bad.

> This is connected to Alvaro's work to create proper dependencies
> for object owners and privilege entries: once that exists and you
> can't drop a referenced role, there will be no need to allow explicit
> setting of the SYSID for a new user.  Not sure if you want to do any
> of the associated changes in your patch, but if int4 is bugging you
> then feel free to change it.

Ok, I probably will.  Should I be concerned with trying to make
'smallish' patches that build upon each other (ie: change to pg_role
first, then change AclId to Oid, or whatever) or will one larger patch
that takes care of it all be ok?
Thanks,
    Stephen

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dawid Kuroczko
Дата:
Сообщение: Re: Locale agnostic unicode text
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Two-phase commit for 8.1