Thread: Re: [Util] Warn and Remove Invalid GUCs

Shaik Mohammad Mujeeb <mujeeb.sk@zohocorp.com> writes:
> In my patch, I currently warn and remove invalid GUCs from the hashtable. However, as you rightly pointed out, some
ofthese could belong to valid but unregistered prefixes. In such cases, it might not be ideal to remove them outright.
Instead,it could be more helpful to simply warn the user - covering both potential typos and GUCs with valid yet
unregisteredprefixes. 

I kind of doubt that warnings at startup are all that helpful.
People don't look at the postmaster log all that often, and
by the time they start wondering why something isn't acting
as they expect, the log file that had the info may have been
rotated out of existence.

I doubt even more that removing GUCs just because they are
not registered prefixes is sane.

Let me suggest a different way of thinking about this: what
say we extend the pg_file_settings view to mark custom GUCs
that don't correspond to any reserved extension prefix?
"Not a known extension" could be one of the "error" messages
that that view provides.

            regards, tom lane

On Thu, May 22, 2025 at 12:10 PM Shaik Mohammad Mujeeb
<mujeeb.sk@zohocorp.com> wrote:
> In my patch, I currently warn and remove invalid GUCs from the hashtable. However, as you rightly pointed out, some
ofthese could belong to valid but unregistered prefixes. In such cases, it might not be ideal to remove them outright.
Instead,it could be more helpful to simply warn the user - covering both potential typos and GUCs with valid yet
unregisteredprefixes. 
>
> I do understand that not everyone may prefer seeing such warnings during PG server restart. To address this, we could
introducea new GUC (perhaps named warn_on_unregistered_guc_prefix), which defaults to false, preserving the existing
behaviour.If explicitly enabled, it would emit warnings for these cases, giving users the choice to opt in to this
feedback.

I think you might be missing the point of the comments from Tom and
David. To the extent that it is possible to give warnings, we already
do. So this proposal just doesn't really make sense. It either warns
in cases where there is no actual problem, or it gives a duplicate
warning in cases where there is. Changing the details of the proposal
doesn't address that fundamental problem.

I would really encourage you to spend a bit more time trying to
understand the current design intention and behavior before proposing
changes. It actually makes a lot of sense. It is not perfect, but if
there were a simple way to do better we would have likely done that a
long time ago.

--
Robert Haas
EDB: http://www.enterprisedb.com