Handle case when a GUC type is different

[anayrat]

For example, wal_compression was a boolean before 15, then it changed to an enum type which allows different kind of compression algorithm.

Thanks for your tool, very helpful :)

[rustprooflabs]

Thanks for the suggestion! In the current state there's not really a good way to track that change. Everything is driven off of parsing the config files with default values at runtime.

I think the idea I had in #3 might actually work towards this. I hadn't included the min_val, max_val or enumvals columns before, but that would probably move towards what you're looking for here. I see the enumvals column has these options in Pg15:

enumvals              |
----------------------+
{pglz,lz4,zstd,on,off}|

If you have other ideas on how to approach this, and how to visualize that in the webapp, I'm all ears! It'll probably be a while before I have time to hack at this, PRs always welcome. :)

SELECT name, setting, context, source, reset_val, boot_val,
        unit, category,
        name || ' = ' ||  setting AS postgresconf_line,
        name || ' = ' || boot_val AS default_config_line,
        short_desc,
        CASE WHEN name LIKE 'lc%'
                THEN True
            WHEN name IN ('application_name', 'TimeZone')
                THEN True
            ELSE False
            END AS frequent_override,
        CASE WHEN boot_val = reset_val THEN True 
            ELSE False 
            END AS system_default,
        CASE WHEN reset_val = setting THEN False 
            ELSE True
            END AS session_override, 
        pending_restart,
        min_val, max_val, enumvals
    FROM pg_catalog.pg_settings
;

[rustprooflabs]

@anayrat #17 will implement this! Screenshots in comment #17 (comment) illustrate wal_compression changes on the version comparison page and the single parameter history page.

Still have some cleanup to do, but it's getting close to ready to merge.

[anayrat]

Nice ! thank you !

[rustprooflabs]

Added via #17, deployed to prod. :)