Re: [HACKERS] Removal of deprecated views pg_user, pg_group,pg_shadow

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: [HACKERS] Removal of deprecated views pg_user, pg_group,pg_shadow
Дата
Msg-id 20170210060436.GM9812@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: [HACKERS] Removal of deprecated views pg_user, pg_group, pg_shadow  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Removal of deprecated views pg_user, pg_group,pg_shadow  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список pgsql-hackers
Tom,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > The question of removing the pre-role, deprecated, views of pg_user,
> > pg_group and pg_shadow has come up again.
>
> > I figured a new thread was in order, however, to allow others to weigh
> > in on it.
>
> > Note that these views have not been consistently maintained and have
> > ended up including some role attributes from recent versions (eg:
> > bypassrls) but were missed when others were added (eg: createrole).
> > There are properly maintained and cared for role-based versions of all
> > of these views, which are pg_roles, pg_auth_members, and pg_authid,
> > respectively.
>
> Umm ... what exactly is the argument that those views are really better,
> and are not just destined to become legacy views in their turn?

The pg_auth_members view includes more information about the role
relationships (who the grantor is, if the admin option has been granted)
and it also frames the relationships in the multi-level directed acyclic
graph structure that truely represents what role membership means.  The
pg_roles view includes *all* of the role attributes, not just an
arbitrary (and entirely unintentional, as far as I can tell) subset of
them.

> > As we move forward with the other many changes in PG10, it seems like a
> > good time to remove these inconsistent and ancient views that were
> > introduced when roles were added in 2005.
>
> This sounds like "v10 is a great time to break stuff", which we've
> already agreed is not project policy.

How about "it's not a bad time to break stuff."

> If there's a positive reason why these old views are impeding progress,
> then let's remove 'em, but I don't think you've presented one.  What
> exactly will it hurt to leave them there?

They're misleading by having an arbitrary subset of the role attributes
and implying that the role relationships are simpler than they actually
are.  Frankly, they're also not being consistently maintained based on
any proper policy, which I find quite objectionable.  I'll admit that I
hold PG to a pretty high standard when it comes to such things, but
that's simply because I have a very vested interest in having users feel
that PG is a solid, well designed, and well maintained database system.
These half-forgotten warts detract from that, even when they're warts
that I wrote in the first place.  12-year-ago me simply didn't have the
experience that now-me does, or the foresight to predict that these
views would still be hanging around at this point.

Of course, we could fix these issues- we could add the grantor to the
pg_groups view, and perhaps even change it to be an acyclic directed
graph structure, and we could add the role attributes to pg_user and
pg_shadow which are missing, but at that point all we're really doing,
it seems to me, is providing synonyms for the existing canonical views,
and that hardly seems useful.

Thanks!

Stephen

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

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: [HACKERS] Declarative partitioning - another take
Следующее
От: Claudio Freire
Дата:
Сообщение: Re: [HACKERS] Improve OR conditions on joined columns (common starschema problem)