From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: is_superuser versus set_config_option's parallelism check |
Date: | 2024-08-10 14:26:38 |
Message-ID: | Zrd4nlH-YJkU89q5@nathan |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 re-word it to be more like all the other can't-set-this-now
> errors just below it. I'm half tempted to change the errcode and
> set_config_option return value to match the others too, ie
> ERRCODE_CANT_CHANGE_RUNTIME_PARAM and "return 0" not -1.
> I don't think the existing choices here are very well thought
> through, and they're certainly inconsistent with a lot of
> otherwise-similar-seeming refusals in set_config_option.
This comment for set_config_option() leads me to think we should be
returning -1 instead of 0 in many more places in set_config_with_handle():
* Return value:
* +1: the value is valid and was successfully applied.
* 0: the name or value is invalid (but see below).
* -1: the value was not applied because of context, priority, or changeVal.
But I haven't thought through it, either. At this point, maybe the comment
is wrong...
--
nathan
From | Date | Subject | |
---|---|---|---|
Next Message | Jelte Fennema-Nio | 2024-08-10 14:27:02 | Re: libpq: Fix lots of discrepancies in PQtrace |
Previous Message | vignesh C | 2024-08-10 14:23:04 | Re: Pgoutput not capturing the generated columns |