Re: [Util] Warn and Remove Invalid GUCs

Hi Tom Lane,

> Well, yeah, because the core server has no way to identify bogus

> extension GUCs if the relevant extension isn't loaded.  We do

> already complain about such things at extension load time.

Yes, currently we do issue warnings at extension load time if a GUC with a valid prefix contains an invalid or misspelled suffix (e.g., plpgsql.bogus, plpgsql.abc, plpgsql.xyz). In such cases, only the part after the dot is invalid, so the warning helps users catch typos early.

However, if the typo exists in the extension name itself (e.g., plppsql.extra_errors, plpgaql.extra_errors, plpgsqi.extra_errors), we currently don’t provide any acknowledgment. In these examples, the prefix is invalid or misspelled, and it would be helpful to notify the user so they have a chance to correct it.

I do agree that in cases of unrecognised prefixes, it’s possible they may either be typos or valid but unregistered prefixes. So instead of removing such GUCs from the hashtable - as my current patch does - it would be more appropriate to just issue a warning.

Of course, I understand that not all users may want to see these warnings. To make this behaviour optional, we could introduce a new GUC (e.g., warn_on_unregistered_guc_prefix), which defaults to false to preserve existing behaviour. When set to true, it would enable warnings for unregistered or potentially misspelled GUC prefixes, giving users the flexibility to opt in.

> How will you know they are invalid?  All I see in the patch is

> a syntactic check, which looks quite redundant with

> assignable_custom_variable_name().

After all the shared preload libraries are loaded, the reserved_class_prefix list contains the valid prefixes which we can refer to for this validation. I’m performing this check only after all such libraries are loaded. While this might look similar to the logic in assignable_custom_variable_name(), the purpose here is different.

I hope this helps clarify the intention behind the proposal, and I’d appreciate any thoughts or feedback on this approach.

Thanks & Regards,

Shaik Mohammad Mujeeb

Member Technical Staff

Zoho Corp

---- On Thu, 22 May 2025 02:08:58 +0530 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote ---

Shaik Mohammad Mujeeb <mailto:mujeeb(dot)sk(at)zohocorp(dot)com> writes:
> Currently, if there's a typo in an extension name while adding a GUC to postgresql.conf, PostgreSQL server starts up silently without any warning. This can be misleading, as one might assume the configuration has been correctly applied, when in fact the value hasn’t been set due to the typo.

Well, yeah, because the core server has no way to identify bogus
extension GUCs if the relevant extension isn't loaded. We do
already complain about such things at extension load time.

> To improve this experience, I’m proposing a patch that issues a
> warning for such invalid GUC entries.

How will you know they are invalid? All I see in the patch is
a syntactic check, which looks quite redundant with
assignable_custom_variable_name().

            regards, tom lane