Re: Per-Database Roles

From: Florian Pflug <fgp(at)phlo(dot)org>
To: Thom Brown <thom(at)linux(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Per-Database Roles
Date: 2012-05-22 16:23:56
Message-ID: 0C48E6F9-FE87-47E8-B87E-0A0A6F1EDA66@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On May22, 2012, at 18:03 , Thom Brown wrote:
> On 22 May 2012 16:57, Florian Pflug <fgp(at)phlo(dot)org> wrote:
>> On May22, 2012, at 16:09 , Tom Lane wrote:
>>> Thom Brown <thom(at)linux(dot)com> writes:
>>>> Conflicts would occur where localrolename matches an existing local
>>>> role name within the same database, or a global role name, but not a
>>>> local role name within another database. The problem with this,
>>>> however, is that creating global roles would need conflict checks
>>>> against local roles in every database, unless a manifest of all local
>>>> roles were registered globally.
>>>
>>> Yeah. The same type of issue arises for the roles' OIDs. You'd really
>>> want local and global roles to have nonconflicting OIDs, else it's
>>> necessary to carry around an indication of which type each role is;
>>> which would be more or less a show-stopper in terms of the number of
>>> catalogs and internal APIs affected. But I don't currently see any
>>> nice way to guarantee that if each database has a private table of
>>> local roles.
>>
>> Maybe we could simply make all global role's OIDs even, and all local ones
>> odd, or something like that.
>
> Wouldn't that instantly make all previous versions of database
> clusters un-upgradable?

Only if pg_upgrade needs to preserve the OIDs of roles. I kinda hoped it
wouldn't, because role OIDs aren't usually stored in non-system tables.

Hm… thinking about this further, it'd actually be sufficient for all newly
allocated role OIDs to follow the odd/even rule, if we additionally check
for conflicts with existing global role OIDs when allocating the OID of a new
local role. Which is much, much easier than checking for conflicts when
allocating a global OIDs, because for that you'd have to check against the
local role OIDs within *all* databases, not just against one shared table.

best regards,
Florian Pflug

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2012-05-22 16:28:40 Re: Exclusion Constraints on Arrays?
Previous Message Robert Haas 2012-05-22 16:23:14 Re: Readme of Buffer Management seems to have wrong sentence