On Thu, May 13, 2021 at 04:15:30PM +0900, Kyotaro Horiguchi wrote:
> >
> > what if you want to have some other extensions like pg_stat_kcache or
> > pg_store_plans that need a query_id but don't really care if
> > pg_stat_statements is enabled or not? should they all declare their own
>
> Thanks for looking it.
>
> The addtional provider function in pg_stat_statements is just an
> example to show what if it needs its own query-id provider, which is
> useless in reality. In reality pg_stat_statements just calls
> "queryIdWanted("default", true)" to use any query-id provider and use
> the in-core one as the fallback implement, and no need to define its
> own one.
>
> Any extension can use the in-core provider and accepting any other
> ones by calling queryIdWanted("default", true) then get what they want
> regardless of existence of pg_stat_statements.
I see, thanks for the clarification. So I looked a bit at the implementation,
mostly the new queryIdWanted() and check_query_id_provider(), it seems a bit
inconsistent.
It's not clear to me how this should be used. It seems that it's designed to
allow any plugin to activate a query_id implementation, but if a third-party
query_id provider tries to activate its own implementation it will fail if you
also want to use pg_stat_statements as both will try to activate incompatible
implementations. It seems to me that queryIdWanted() should only be used for
enabling core query_id if the configuration allows the core implementation to
be enabled, and everything else should be manually configured by users, so
there shouldn't be a provider_name.
