Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost <sfr...@snowman.net> writes: > > * Magnus Hagander (mag...@hagander.net) wrote: > >> Thatäs why I suggested the three value one. Default to a mode where > >> it's automatic, which is what the majority is going to want, but have > >> a way to explicitly turn it on. > > > This is certainly fine with me too, though it seems a bit surprising to > > me that we couldn't just figure out what the user actually wants based > > on what's installed/running for any given combination. > > I'd be on board with having pg_stat_statement's pg_init function do > something to adjust the setting, if we can figure out how to do that > in a way that's not confusing in itself. I'm not sure though that > the GUC engine offers a good way.
Both of the extensions are getting loaded via pg_stat_statements and both can have pg_init functions which work together to come up with the right answer, no? That is- can't pg_stat_statements, when it's loaded, enable compute_query_id if it's not already enabled, and then the pg_queryid module simply disable it when it gets loaded in it's pg_init()? Telling people who are using pg_queryid to have it loaded *after* pg_stat_statements certainly seems reasonable to me, but if folks don't like that then maybe have a tri-state which is 'auto', 'on', and 'off', where pg_stat_statements would set it to 'on' if it's set to 'auto', but not do anything if it starts as 'off'. pg_queryid would then set it to 'off' when it's loaded and it wouldn't matter if it's loaded before or after. Thanks, Stephen
signature.asc
Description: PGP signature
