Re: Allow placeholders in ALTER ROLE w/o superuser

On Wed, Dec 7, 2022 at 1:28 AM Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com> wrote:
> On Tue, 6 Dec 2022 at 19:01, Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
> >
> > On Mon, Dec 5, 2022 at 10:32 PM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
> > > On Mon, Dec 5, 2022 at 8:18 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > > > Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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.

Thank you, Pavel.
I've made few minor improvements in the docs and comments.
I'm going to push this if no objections.

------
Regards,
Alexander Korotkov