On Tue, Feb 11, 2025 at 08:57:46PM -0600, Sami Imseih wrote: > > Of course some people may want to keep the current behavior, if they have > > limited number of temp tables or similar, so I had a GUC for that. I don't > > think that the community would really welcome such GUC for core-postgres, > > especially since it wouldn't be pg_stat_statements specific. > > FWIW, I think options to tweak queryId computation is something > that should be in core. It was discussed earlier in the context > of IN list merging; the patch for this currently has the guc > for the feature in pg_stat_statements, but there was a discussion > about actually moving this to core [1] Giving the user a way > to control certain behavior about the queryId computation > is a good thing to do in core; especially queryId is no longer > just consumed in pg_stat_statements. Maybe the right answer > is an enum GUC, not sure yet. > > Specifically for the use-case you mention, using names vs OIDs in > queryId computation is a valid use case for more than temporary tables, > I can also think of upgrade, dump/restore, logical replication cases which > can then allow for a consistent queryId.
Well, the ability for extensions to override the actual queryid calculation was the result of more than half a decade of strong disagreements about it. And I'm definitely not volunteering to reopen that topic :)
