On Fri, May 14, 2021 at 12:04:05PM -0400, Andrew Dunstan wrote:
>
> > On May 14, 2021, at 8:35 AM, Bruce Momjian <bruce@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 <bruce@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.
