Thread: Custom GUCs and typos
Hi,
while going through this thread [0] i have some different views and questions on this problem so creating a separate thread,this is just an attempt, i might be brutally wrong here.
while going through this thread [0] i have some different views and questions on this problem so creating a separate thread,this is just an attempt, i might be brutally wrong here.
1) On top of OP's patch I added support to warn if the prefix of custom GUC is invalid,for valid questions such as "How do you know that's a bogus prefix? It could perfectly well be a fully valid setting for an extension that the installation doesn't choose to preload.",we can get the info of such extensions using extension_file_exists() which tells that its installed but not preloaded thanks to Greg for proposing this,which tells this could be a potential valid extension ,so if its not it in reserved_class_prefix and also not in prefix/share/extension dir then the prefix is for sure invalid,so i warn and remove the GUC from hashtable.
2) for preloaded extensions if the suffix/parameter is a typo or if we want to create a new custom GUC for ex:"pg_stat_statements.count_something = 1", currently we throwing a warning as
WARNING: invalid configuration parameter name "pg_stat_statements.count_something", removing it
2) for preloaded extensions if the suffix/parameter is a typo or if we want to create a new custom GUC for ex:"pg_stat_statements.count_something = 1", currently we throwing a warning as
WARNING: invalid configuration parameter name "pg_stat_statements.count_something", removing it
"pg_stat_statements" is now a reserved prefix.
I guess this means you cant create a new custom GUC manually ,you have to use "DefineCustomXXXVariable" routines,but this kind of warning is not there for non-preloaded extensions ,so i added the same for non-preloaded ones ,once again checking the extension_file_exists() if the extension was built/installed this could make it a potential valid extension so it warns as
I guess this means you cant create a new custom GUC manually ,you have to use "DefineCustomXXXVariable" routines,but this kind of warning is not there for non-preloaded extensions ,so i added the same for non-preloaded ones ,once again checking the extension_file_exists() if the extension was built/installed this could make it a potential valid extension so it warns as
if i try add this "plpgsql.ironman = 3000"
WARNING: invalid configuration parameter name "plpgsql.ironman", removing it
DETAIL: "plpgsql.ironman" has a valid prefix.
3) I also added all the above support for the SET command also which previously was not there.
4) TODO: add support for ALTER SYSTEM SET ,if this patch makes sense.
thoughts?
[0] https://www.postgresql.org/message-id/flat/196f3f8e12f.87666a6c16169.9160742057750715009%40zohocorp.com
-- WARNING: invalid configuration parameter name "plpgsql.ironman", removing it
DETAIL: "plpgsql.ironman" has a valid prefix.
3) I also added all the above support for the SET command also which previously was not there.
4) TODO: add support for ALTER SYSTEM SET ,if this patch makes sense.
thoughts?
[0] https://www.postgresql.org/message-id/flat/196f3f8e12f.87666a6c16169.9160742057750715009%40zohocorp.com
Attachment
On Sun, May 25, 2025 at 7:52 PM Srinath Reddy Sadipiralla <srinath2133@gmail.com> wrote:
1) On top of OP's patch I added support to warn if the prefix of custom GUC is invalid,for valid questions such as "How do you know that's a bogus prefix? It could perfectly well be a fully valid setting for an extension that the installation doesn't choose to preload.",we can get the info of such extensions using extension_file_exists() which tells that its installed but not preloaded thanks to Greg for proposing this,which tells this could be a potential valid extension ,so if its not it in reserved_class_prefix and also not in prefix/share/extension dir then the prefix is for sure invalid,so i warn and remove the GUC from hashtable.
People can and do create GUCs without any intention or need to write C code or place files onto the server to make use of them.
"PostgreSQL will accept a setting for any two-part parameter name."
We cannot change this. So, please include discussion of their existence in any description of changes you wish to make in this area.
David J.