On Fri, May 14, 2021 at 12:04:05PM -0400, Andrew Dunstan wrote: > > > On May 14, 2021, at 8:35 AM, Bruce Momjian <br...@momjian.us> wrote: > > > > On Thu, May 13, 2021 at 09:41:42PM -0400, Bruce Momjian wrote: > >>> On Fri, May 14, 2021 at 09:40:15AM +0800, Julien Rouhaud wrote: > >>> On Fri, May 14, 2021 at 8:13 AM Bruce Momjian <br...@momjian.us> wrote: > >>>> > >>>> On Thu, May 13, 2021 at 08:04:37PM -0400, Álvaro Herrera wrote: > >>>>> Here's a first attempt at what was suggested. If you say "auto" it > >>>>> remains auto in SHOW, but it gets enabled if a module asks for it. > >>>>> > >>>>> Not final yet, but I thought I'd throw it out for early commentary ... > >>>> > >>>> I certainly like this idea better than having the extension change the > >>>> output of the GUC. > >>> > >>> Oh, I didn't understand that it was the major blocker. I'm fine with it > >>> too. > >> > >> I think if we keep the output as 'auto', and document that you check > >> pg_stat_activity for a hash to see if it is enabled, that gets us pretty > >> far. > > > > I think keeping the output as 'auto', and documenting that this query > > must be run to determine if the query id is being computed: > > > > SELECT query_id > > FROM pg_stat_activity > > WHERE pid = pg_backend_pid(); > > > > is the right approach. > > I’d rather we added a specific function. This is not really obvious.
We could, but I don't know how much this will be used in practice. The only way someone would try to know if "auto" means that query_id are computed is if she has an extension like pg_stat_statements, and she will probably just check that anyway, and will get a warning if query_id are *not* computed. That being said no objection to an SQL wrapper around a query like it.