Re: Emit a warning if the extension's GUC is set incorrectly

Florin Irion <irionr(at)gmail(dot)com> writes:
> Il giorno ven 18 feb 2022 alle ore 10:58 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> ha
> scritto:
>> Here's a delta patch (meant to be applied after reverting cab5b9ab2)
>> that does things like that. It fixes the parallel-mode problem ...
>> so do we want to tighten things up this much?

> Thank you for taking care of the bug I introduced with 75d22069e,
> I didn't notice this thread until now.

Yeah, this thread kinda disappeared under the rug during the Christmas
holidays, but we need to decide whether we want to push forward or
leave things at the status quo.

> For what it's worth, I agree with throwing an ERROR if the placeholder is
> unrecognized. Initially, I didn't want to change too much the liberty of
> setting any placeholder, but mainly to not go unnoticed.

I also think that this is probably a good change to make.

One situation where somebody would be unhappy is if they're using GUC
variables as plain custom variables despite them being within the
namespace of an extension they're using. But that seems to me to be
(a) far-fetched and (b) mighty dangerous, since some new version of the
extension might suddenly start reacting to those variables in ways you
presumably didn't expect.

Perhaps a more plausible use-case is "I need to work with both versions
X and Y of extension E, and Y has setting e.foo while X doesn't --- but
I can just set e.foo unconditionally since X will ignore it". With this
patch, that could still work, but you'd have to be certain to apply the
setting before loading E.

I don't really see any other use-cases favoring the current behavior.
On balance, eliminating possible mistakes seems like enough of a
benefit to justify disallowing these cases.

regards, tom lane