"System roles" mentioned in psql documentation
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t76296psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 12:54 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t76296_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t76296_1 && git checkout t76296_1Patchset v1 (message #1) is on t76296_1
Hi all,
I have noticed that psql documentation mentions "system roles", however
in all other parts of the docs, we use the term "default roles".
Shouldn't we make this term more consistent and also add a link to the
table describing those roles? Please see the attached.
Thanks,
--
Michael
This inconsistency is part of the more general problem that we miss a
chapter, where our basic terms like 'database', 'cluster', 'segment',
'catalog', 'schema', ... are explicitly defined.
Kind regards
J�rgen Purtz
On Aug 23, 2018, at 3:58 AM, Michael Paquier <michael@paquier.xyz> wrote:
Hi all,
I have noticed that psql documentation mentions "system roles", however
in all other parts of the docs, we use the term "default roles".
Shouldn't we make this term more consistent and also add a link to the
table describing those roles? Please see the attached.
I did a quick search for other cases of “system roles” with nothing coming
up, so it looks like you caught the only reference. LGTM.
Thanks!
Jonathan
On Thu, Aug 23, 2018 at 10:53:35AM +0200, Jürgen Purtz wrote:
This inconsistency is part of the more general problem that we miss a
chapter, where our basic terms like 'database', 'cluster', 'segment',
'catalog', 'schema', ... are explicitly defined.
You may have a point here, not in the way of reworking entirely the
documentation, but in the fact that we may want to use "system objects"
instead of "system roles". I am not personally sure that it is a better
improvement than using "default roles", but that's a point to raise.
--
Michael
On 24.08.2018 02:21, Michael Paquier wrote:
On Thu, Aug 23, 2018 at 10:53:35AM +0200, J�rgen Purtz wrote:
This inconsistency is part of the more general problem that we miss a
chapter, where our basic terms like 'database', 'cluster', 'segment',
'catalog', 'schema', ... are explicitly defined.You may have a point here, not in the way of reworking entirely the
documentation, but in the fact that we may want to use "system objects"
instead of "system roles". I am not personally sure that it is a better
improvement than using "default roles", but that's a point to raise.
--
Michael
First, the intention of my note was to improve the complete
documentation by defining the meaning of important terms in a separate
chapter. The discussion about "system roles" and "default roles" is only
one of many points where we use terms in a fuzzy way.
Second (and this seems to be the point of your mail), the term "role" is
loosely described at the beginning of chapter 21 "A role can be thought
of as either a database user, or ... ". In contrast to this description
chapter 21.5 and table 21.1. use the term "role" very differently. Here
it is used in the sense of a "capability", a "right", a "permission", an
"allowed access" ... . This cumulates in the example at the bottom:
"GRANT pg_signal_backend TO admin_user;"� What is the "role", the
"pg_signal_backend" or the "admin_user"?
Kind regards
J�rgen Purtz