Hi, On 2022-03-31 16:16:31 +0900, Kyotaro Horiguchi wrote: > After moving to shared stats, we might want to expose the GUC variable > itself. Then hide/remove the macro PG_STAT_TMP_DIR. This breaks the > extensions but it is better than keeping using PG_STAT_TMP_DIR for > uncertain reasons. The existence of the macro can be used as the > marker of the feature change. This is the chance to break the (I > think) bad practice shared among the extensions. At least I am okay > with that.
I don't really understand why we'd want to do it that way round? Why not just leave PG_STAT_TMP_DIR in place, and remove the GUC? Since nothing uses the GUC, we're not loosing anything, and we'd not break extensions unnecessarily? Obviously there's no strong demand for pg_stat_statements et al to use the user-configurable stats_temp_directory, given they've not done so for years without complaints? The code to support the configurable stats_temp_dir isn't huge, but it's not small either. Greetings, Andres Freund