Re: Allow placeholders in ALTER ROLE w/o superuser

Hi, Alexander!

On Tue, 6 Dec 2022 at 19:01, Alexander Korotkov <aekorotkov@gmail.com> wrote:
>
> On Mon, Dec 5, 2022 at 10:32 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:
> > On Mon, Dec 5, 2022 at 8:18 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > > Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> > > > I couldn't find any discussion of the idea of adding "(s)" to the
> > > > variable name in order to mark the variable userset in the catalog, and
> > > > I have to admit I find it a bit strange.  Are we really agreed that
> > > > that's the way to proceed?
> > >
> > > I hadn't been paying close attention to this thread, sorry.
> > >
> > > I agree that that seems like a very regrettable choice,
> > > especially if you anticipate having to bump catversion anyway.
> >
> > I totally understand that this change requires a catversion bump.
> > I've reflected this in the commit message.
> >
> > > Better to add a bool column to the catalog.
> >
> > What about adding a boolean array to the pg_db_role_setting? So,
> > pg_db_role_setting would have the following columns.
> >  * setdatabase oid
> >  * setrole oid
> >  * setconfig text[]
> >  * setuser bool[]
>
> The revised patch implements this way for storage USER SET flag.
> think it really became more structured and less cumbersome.

I agree that the patch became more structured and the complications
for string parameter suffixing have gone away. I've looked it through
and don't see problems with it. The only two-lines fix regarding
variable initializing may be relevant (see v9). Tests pass and CI is
also happy with it. I'd like to set it ready for committer if no
objections.

Regards,
Pavel Borisov,
Supabase.