Thread: Should we remove db_user_namespace?
I think this is the second decennial thread [0] for removing this GUC. This topic came up at PGCon, so I thought I'd start the discussion on the lists. I'm personally not aware of anyone using this parameter. A couple of my colleagues claimed to have used it in the aughts, but they also noted that users were confused by the current implementation, and they seemed generally in favor of removing it. AFAICT the strongest reason for keeping it is that there is presently no viable replacement. Does this opinion still stand? If so, perhaps we can look into adding a viable replacement for v17. The attached patch simply removes the GUC. [0] https://postgr.es/m/CAA-aLv6wnwp6Qr5fZo%2B7K%3DVSr51qFMuLsCeYvTkSF3E5qEPvqA%40mail.gmail.com -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
Attachment
On Fri, Jun 30, 2023 at 01:05:09PM -0700, Nathan Bossart wrote: > The attached patch simply removes the GUC. And here's a new version of the patch with docs that actually build. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
Attachment
On Fri, Jun 30, 2023 at 01:05:09PM -0700, Nathan Bossart wrote: > I think this is the second decennial thread [0] for removing this GUC. > This topic came up at PGCon, so I thought I'd start the discussion on the > lists. > > I'm personally not aware of anyone using this parameter. A couple of my > colleagues claimed to have used it in the aughts, but they also noted that > users were confused by the current implementation, and they seemed > generally in favor of removing it. AFAICT the strongest reason for keeping > it is that there is presently no viable replacement. Does this opinion > still stand? If so, perhaps we can look into adding a viable replacement > for v17. I am the original author, and it was a hack designed to support per-database user names. I am fine with its removal. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.
Nathan Bossart <nathandbossart@gmail.com> writes:
> I'm personally not aware of anyone using this parameter.
Might be worth asking on pgsql-general whether anyone knows of
active use of this feature. If not, I'm good with killing it.
regards, tom lane
On Fri, Jun 30, 2023 at 05:29:04PM -0400, Bruce Momjian wrote: > I am the original author, and it was a hack designed to support > per-database user names. I am fine with its removal. Thanks, Bruce. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
On Fri, Jun 30, 2023 at 05:40:18PM -0400, Tom Lane wrote: > Might be worth asking on pgsql-general whether anyone knows of > active use of this feature. If not, I'm good with killing it. Will do. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
On Fri, Jun 30, 2023 at 11:43 PM Nathan Bossart <nathandbossart@gmail.com> wrote: > > On Fri, Jun 30, 2023 at 05:40:18PM -0400, Tom Lane wrote: > > Might be worth asking on pgsql-general whether anyone knows of > > active use of this feature. If not, I'm good with killing it. > > Will do. Strong +1 from here for removing it, assuming you don't find a bunch of users on -general who are using it. Having never come across one myself, I think it's unlikely, but I agree it's good to ask. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
On Sat, Jul 01, 2023 at 12:13:26AM +0200, Magnus Hagander wrote: > Strong +1 from here for removing it, assuming you don't find a bunch > of users on -general who are using it. Having never come across one > myself, I think it's unlikely, but I agree it's good to ask. Cool. I'll let that thread [0] sit for a while. [0] https://postgr.es/m/20230630215608.GD2941194%40nathanxps13 -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
On Fri, Jun 30, 2023 at 01:05:09PM -0700, Nathan Bossart wrote: > The attached patch simply removes the GUC. I am on the side of +1'ing for the removal. -- Michael
Attachment
On Mon, Jul 03, 2023 at 04:20:39PM +0900, Michael Paquier wrote: > I am on the side of +1'ing for the removal. Here is a rebased version of the patch. So far no one has responded to the pgsql-general thread [0], and no one here has argued for keeping this parameter. I'm planning to bump the pgsql-general thread next week to give folks one more opportunity to object. [0] https://postgr.es/m/20230630215608.GD2941194%40nathanxps13 -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
Attachment
On Wed, Jul 05, 2023 at 02:29:27PM -0700, Nathan Bossart wrote:
> },
> - {
> - {"db_user_namespace", PGC_SIGHUP, CONN_AUTH_AUTH,
> - gettext_noop("Enables per-database user names."),
> - NULL
> - },
> - &Db_user_namespace,
> - false,
> - NULL, NULL, NULL
> - },
> {
Removing the GUC from this table is kind of annoying. Cannot this be
handled like default_with_oids or ssl_renegotiation_limit to avoid any
kind of issues with the reload of dump files and the kind?
--
Michael
Attachment
On Thu, Jul 06, 2023 at 08:21:18AM +0900, Michael Paquier wrote: > Removing the GUC from this table is kind of annoying. Cannot this be > handled like default_with_oids or ssl_renegotiation_limit to avoid any > kind of issues with the reload of dump files and the kind? Ah, good catch. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
Attachment
On Wed, Jul 05, 2023 at 08:49:26PM -0700, Nathan Bossart wrote: > On Thu, Jul 06, 2023 at 08:21:18AM +0900, Michael Paquier wrote: >> Removing the GUC from this table is kind of annoying. Cannot this be >> handled like default_with_oids or ssl_renegotiation_limit to avoid any >> kind of issues with the reload of dump files and the kind? > > Ah, good catch. Thanks. Reading through the patch, this version should be able to handle the dump reloads. -- Michael
Attachment
On Mon, Jul 10, 2023 at 03:43:07PM +0900, Michael Paquier wrote: > Thanks. Reading through the patch, this version should be able to > handle the dump reloads. Thanks for reviewing. I'm currently planning to commit this sometime next week. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
On Mon, Jul 10, 2023 at 03:43:07PM +0900, Michael Paquier wrote: > On Wed, Jul 05, 2023 at 08:49:26PM -0700, Nathan Bossart wrote: >> On Thu, Jul 06, 2023 at 08:21:18AM +0900, Michael Paquier wrote: >>> Removing the GUC from this table is kind of annoying. Cannot this be >>> handled like default_with_oids or ssl_renegotiation_limit to avoid any >>> kind of issues with the reload of dump files and the kind? >> >> Ah, good catch. > > Thanks. Reading through the patch, this version should be able to > handle the dump reloads. Hm. Do we actually need to worry about this? It's a PGC_SIGHUP GUC, so it can only be set at postmaster start or via a configuration file. Any dump files that are trying to set it or clients that are trying to add it to startup packets are already broken. I guess keeping the GUC around would avoid breaking any configuration files or startup scripts that happen to be setting it to false, but I don't know if that's really worth worrying about. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
On Sat, Jul 15, 2023 at 1:34 AM Nathan Bossart <nathandbossart@gmail.com> wrote: > > On Mon, Jul 10, 2023 at 03:43:07PM +0900, Michael Paquier wrote: > > On Wed, Jul 05, 2023 at 08:49:26PM -0700, Nathan Bossart wrote: > >> On Thu, Jul 06, 2023 at 08:21:18AM +0900, Michael Paquier wrote: > >>> Removing the GUC from this table is kind of annoying. Cannot this be > >>> handled like default_with_oids or ssl_renegotiation_limit to avoid any > >>> kind of issues with the reload of dump files and the kind? > >> > >> Ah, good catch. > > > > Thanks. Reading through the patch, this version should be able to > > handle the dump reloads. > > Hm. Do we actually need to worry about this? It's a PGC_SIGHUP GUC, so it > can only be set at postmaster start or via a configuration file. Any dump > files that are trying to set it or clients that are trying to add it to > startup packets are already broken. I guess keeping the GUC around would > avoid breaking any configuration files or startup scripts that happen to be > setting it to false, but I don't know if that's really worth worrying > about. I'd lean towards "no". A hard break, when it's a major release, is better than a "it stopped having effect but didn't tell you anything" break. Especially when it comes to things like startup scripts etc. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
On Sun, Jul 16, 2023 at 01:24:06PM +0200, Magnus Hagander wrote: > I'd lean towards "no". A hard break, when it's a major release, is > better than a "it stopped having effect but didn't tell you anything" > break. Especially when it comes to things like startup scripts etc. Committed. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com