MIME-Version: 1.0
References: 
 <2023185982.281851219.1646733038464.JavaMail.root@zimbra15-e2.priv.proxad.net>
 <1712096587.208766558.1706090901073.JavaMail.zimbra@free.fr>
 <bd4c8b8e88548d6e08220196a02c17d4fa5d2124.camel@cybertec.at>
 <EC6A3402-8271-4EA7-B6BA-1CEFEA96C749@yesql.se>
 <0a933e91f59b59f14734e19e8575894a2a06a7f2.camel@cybertec.at>
In-Reply-To: <0a933e91f59b59f14734e19e8575894a2a06a7f2.camel@cybertec.at>
From: =?UTF-8?B?Sm9zZWYgxaBpbcOhbmVr?= <josef.simanek@gmail.com>
Date: Sun, 2 Nov 2025 18:25:01 +0100
Message-ID: 
 <CAFp7Qwo=FxcLS23-XkJ+sXmUECfnVZkXo96ru=X9JG+g_62J5A@mail.gmail.com>
Subject: Re: SQL command : ALTER DATABASE OWNER TO
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Daniel Gustafsson <daniel@yesql.se>, gparc@free.fr,
	pgsql-docs <pgsql-docs@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAFp7Qwo%3DFxcLS23-XkJ%2BsXmUECfnVZkXo96ru%3DX9JG%2Bg_62J5A%40mail.gmail.com>
Precedence: bulk

ne 2. 11. 2025 v 18:23 odes=C3=ADlatel Laurenz Albe
<laurenz.albe@cybertec.at> napsal:
>
> On Wed, 2024-01-24 at 15:26 +0100, Daniel Gustafsson wrote:
> > > On 24 Jan 2024, at 15:23, Laurenz Albe <laurenz.albe@cybertec.at> wro=
te:
> > >
> > > On Wed, 2024-01-24 at 11:08 +0100, gparc@free.fr wrote:
> > > > for this "ALTER DATABASE" form, it should be mentioned that after e=
xecution of the command,
> > > > the old database owner loses all his privileges on it (even connect=
ion) although it might
> > > > still owns schemas or objects (tables, index,...) inside it.
> > > >
> > > > Thanks in advance to add this important precision.
> > >
> > > How about this:
> > >
> > > diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
> > > index 4044f0908f..44042f863c 100644
> > > --- a/doc/src/sgml/ddl.sgml
> > > +++ b/doc/src/sgml/ddl.sgml
> > > @@ -1891,6 +1891,8 @@ ALTER TABLE <replaceable>table_name</replaceabl=
e> OWNER TO <replaceable>new_owne
> > >    Superusers can always do this; ordinary roles can only do it if th=
ey are
> > >    both the current owner of the object (or inherit the privileges of=
 the
> > >    owning role) and able to <literal>SET ROLE</literal> to the new ow=
ning role.
> > > +   All object privileges of the old owner are transferred to the new=
 owner
> > > +   along with the ownership.
> > >   </para>
> >
> > Doesn't seem unreasonable to me, it won't make the docs harder to read =
and use
> > for experienced users while it may make them easier to follow for new u=
sers.
>
> Here is a patch for this change.

Did a quick test: during review

retro=3D# CREATE USER josef;
CREATE DATABASE testdb OWNER josef;
GRANT ALL ON DATABASE testdb TO josef;
CREATE ROLE
CREATE DATABASE
GRANT
retro=3D# \l testdb
                                                  List of databases
  Name  | Owner | Encoding | Locale Provider |   Collate   |    Ctype
  | ICU Locale | ICU Rules | Access privileges
--------+-------+----------+-----------------+-------------+-------------+-=
-----------+-----------+-------------------
 testdb | josef | UTF8     | libc            | cs_CZ.UTF-8 |
cs_CZ.UTF-8 |            |           | =3DTc/josef        +
        |       |          |                 |             |
  |            |           | josef=3DCTc/josef
(1 row)

retro=3D# ALTER DATABASE testdb OWNER TO retro;
ALTER DATABASE
retro=3D# \l testdb
                                                  List of databases
  Name  | Owner | Encoding | Locale Provider |   Collate   |    Ctype
  | ICU Locale | ICU Rules | Access privileges
--------+-------+----------+-----------------+-------------+-------------+-=
-----------+-----------+-------------------
 testdb | retro | UTF8     | libc            | cs_CZ.UTF-8 |
cs_CZ.UTF-8 |            |           | =3DTc/retro        +
        |       |          |                 |             |
  |            |           | retro=3DCTc/retro
(1 row)

It works exactly as described in this patch. +1

> Yours,
> Laurenz Albe