Re: fixing CREATEROLE

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, walther(at)technowledgy(dot)de, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: fixing CREATEROLE
Date: 2025-05-02 12:04:42
Message-ID: CA+TgmoYoXU_P-ZwEk0reDd2EJ3TNenhUBOK=i3Az4MckhTcX1g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 1, 2025 at 4:31 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> In any case, I'd be happier about createrole_self_grant if it had
> been a role property bit instead of a GUC. But we'd still need
> to worry about whether it corrupts the results of dump/restore
> (offhand I think it still would, if it results in GRANTs that
> weren't there before).

Hmm. That might have been a better design. :-(

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Álvaro Herrera 2025-05-02 12:56:56 Re: queryId constant squashing does not support prepared statements
Previous Message Xuneng Zhou 2025-05-02 10:44:31 Re: Add an option to skip loading missing publication to avoid logical replication failure