On Wed, Dec 7, 2022 at 1:28 AM Pavel Borisov <pashkin.e...@gmail.com> wrote: > On Tue, 6 Dec 2022 at 19:01, Alexander Korotkov <aekorot...@gmail.com> wrote: > > > > On Mon, Dec 5, 2022 at 10:32 PM Alexander Korotkov <aekorot...@gmail.com> > > wrote: > > > On Mon, Dec 5, 2022 at 8:18 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > > > Alvaro Herrera <alvhe...@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.
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
0001-Add-USER-SET-parameter-values-for-pg_db_role_set-v10.patch
Description: Binary data
