On Thu, May 13, 2021 at 12:11:12PM +0900, Kyotaro Horiguchi wrote: > At Thu, 13 May 2021 10:43:03 +0800, Julien Rouhaud <rjuju...@gmail.com> wrote > in > > On Thu, May 13, 2021 at 11:26:29AM +0900, Kyotaro Horiguchi wrote: > > > > > > I believe any "real" > > > alternative query-id provider is supposed to be hooked "before" > > > pg_stat_statements. (It is a kind of magic to control the order of > > > plugins, though.. > > > > Indeed, you have to configure shared_preload_libraries depending on whether > > each module calls the previous post_parse_analyze_hook before or after its > > own > > processing, and that's the main reason why I think a dedicated entry point > > would be better. > > I see it as cleaner than the status-quo. (But still believing less > cleaner than DLL:p, since the same problem happens if two > query_id-generating modules are competing on the new hook ponit.). > > You told that a special query-id provider needed to be separated to > another DLL
No, I'm saying a different entry point. It can be a new hook or an explicit function name called for a dynamically loaded function, I'm fine with both as long as it's called before post_parse_analyze_hook. > It seems like the only problem doing that is we don't have a means to > call per-process intializer for a preload libralies. But that's going to happen only once per backend? If it's still adding too much overhead you could add the module in shared_preload_libraries.
