Re: Emit a warning if the extension's GUC is set incorrectly - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: Emit a warning if the extension's GUC is set incorrectly
Date
Msg-id 20211221.105007.916160321220747245.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: Emit a warning if the extension's GUC is set incorrectly  (Shinya Kato <Shinya11.Kato@oss.nttdata.com>)
List pgsql-hackers
At Fri, 17 Dec 2021 11:25:22 +0900, Shinya Kato <Shinya11.Kato@oss.nttdata.com> wrote in 
> On 2021-12-17 01:55, Fujii Masao wrote:
> > I'm still not sure why you were thinking that ERROR is more proper
> > here.
> 
> Since I get an ERROR when I set the wrong normal GUCs, I thought I
> should also get an ERROR when I set the wrong extension's GUCs.
> However, there are likely to be harmful effects, and I may need to
> think again.

The GUC placeholder mechanism is evidently designed so that server
allows to define variables unknown to the server before loading
extension modules.  ERRORing out that variables at the timing is
contradicting the objective for the placeholder mechanism.

Addition to that EmitWarningsOnPlaceholders()'s objective is to warn
for variables that shouldn't be of a *known* namespace.  However, the
patch is intending to check out variable definitions of all namespaces
that are seen in configuration file, but it is undeterminable at that
time whether each of the namespaces is either just wrong or unknown
yet.  And the latter is, as mentioned above, what we are intending to
allow.

As the concusion, I think we cannot rule-out "wrong" namespaces unless
we find any means to distinguish whether a namespace is wrong or
not-yet-defined before loading extension modules.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: "wangw.fnst@fujitsu.com"
Date:
Subject: RE: Confused comment about drop replica identity index
Next
From: Greg Nancarrow
Date:
Subject: Re: PublicationActions - use bit flags.