Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> On Wed, Mar 17, 2021 at 11:28:38AM -0400, Tom Lane wrote:
>> I still say that it's a serious mistake to sanctify a query ID calculation
>> method that was designed only for pg_stat_statement's needs as the one
>> true way to do it. But that's what exposing it in a core view would do.

> OK, I am fine with creating a new method, and maybe having
> pg_stat_statements use it. Is that the direction we should be going in?

The point is that we've understood Query.queryId as something that
different extensions might calculate differently for their own needs.
In particular it's easy to imagine extensions that want an ID that is
less fuzzy than what pg_stat_statements wants. We never had a plan for
how two such extensions could co-exist, but at least it was possible
to use one if you didn't use another. If this gets moved into core
then there will basically be only one way that anyone can do it.

Maybe what we need is a design for allowing more than one query ID.

> I do think we need _some_ method in core if we are going to be exposing
> this value in pg_stat_activity and log_line_prefix.

I'm basically objecting to the conclusion that we should do either
of those. There is no way around the fact that it will break every
user of Query.queryId other than pg_stat_statements, unless they
are okay with whatever definition pg_stat_statements is using (which
is a moving target BTW).

regards, tom lane