Re: is_superuser versus set_config_option's parallelism check

2024-08-10 Thread Tom Lane
Nathan Bossart writes: > Regarding returning 0 instead of -1 for the parallel case, I think that > follows. While doing some additional research, I noticed this return value > was just added in December (commit 059de3c [0]). Before that, it > apparently assumed that elevel >= ERROR. With that a

Re: is_superuser versus set_config_option's parallelism check

2024-08-10 Thread Nathan Bossart
On Sat, Aug 10, 2024 at 12:57:36PM -0400, Tom Lane wrote: > Yeah, the header comment could stand to be improved to make this > clearer. I think there are more conditions being checked now than > existed when the comment was written. But the para right below the > bit you quoted is pretty clear th

Re: is_superuser versus set_config_option's parallelism check

2024-08-10 Thread Tom Lane
Nathan Bossart writes: > On Fri, Aug 09, 2024 at 06:50:14PM -0400, Tom Lane wrote: >> Also, now that the error depends on which parameter we're talking >> about, I thought it best to include the parameter name in the error >> and to re-word it to be more like all the other can't-set-this-now >> er

Re: is_superuser versus set_config_option's parallelism check

2024-08-10 Thread Nathan Bossart
On Fri, Aug 09, 2024 at 06:50:14PM -0400, Tom Lane wrote: > Here's a draft patch to fix it with a flag, now with regression tests. Looks reasonable. > Also, now that the error depends on which parameter we're talking > about, I thought it best to include the parameter name in the error > and to r

Re: is_superuser versus set_config_option's parallelism check

2024-08-09 Thread Tom Lane
I wrote: > Nathan Bossart writes: >> Another option might be to introduce a new GUC flag or source for anything >> we want to bypass the check (perhaps with the stipulation that it must also >> be marked PGC_INTERNAL). > A new GUC flag seems like a promising approach, and better than > giving a b

Re: is_superuser versus set_config_option's parallelism check

2024-08-09 Thread Tom Lane
Nathan Bossart writes: > On Fri, Aug 09, 2024 at 04:04:15PM -0400, Tom Lane wrote: >> Yeah, I had been thinking along the same lines. Here's a draft >> patch. (Still needs some attention to nearby comments, and I can't >> avoid the impression that the miscinit.c code in this area could >> use re

Re: is_superuser versus set_config_option's parallelism check

2024-08-09 Thread Nathan Bossart
On Fri, Aug 09, 2024 at 04:04:15PM -0400, Tom Lane wrote: > Nathan Bossart writes: >> From a couple of quick tests, it looks like setting >> "current_role_is_superuser" directly works. > > Yeah, I had been thinking along the same lines. Here's a draft > patch. (Still needs some attention to nea

Re: is_superuser versus set_config_option's parallelism check

2024-08-09 Thread Tom Lane
Nathan Bossart writes: > On Fri, Aug 09, 2024 at 02:43:59PM -0400, Tom Lane wrote: >> The simplest fix would be to hack this test to allow the action anyway >> when context == PGC_INTERNAL, excusing that as "assume the caller >> knows what it's doing". That feels pretty grotty though. Perhaps >>

Re: is_superuser versus set_config_option's parallelism check

2024-08-09 Thread Nathan Bossart
On Fri, Aug 09, 2024 at 02:43:59PM -0400, Tom Lane wrote: > The simplest fix would be to hack this test to allow the action anyway > when context == PGC_INTERNAL, excusing that as "assume the caller > knows what it's doing". That feels pretty grotty though. Perhaps > a cleaner way would be to mov