Andres Freund <and...@anarazel.de> writes: > I think that's the right direction. I wonder though if we shouldn't go a > bit further. Have one guc that determines the "query id provider" (NULL > or a shared library), and one GUC that configures whether query-id is > computed (never, on-demand/auto, always). For the provider GUC load the > .so and look up a function with some well known name.
That's sounding like a pretty sane design, actually. Not sure about the shared-library-name-with-fixed-function-name detail, but certainly it seems to be useful to separate "I need a query-id" from the details of the ID calculation. Rather than a GUC per se for the ID provider, maybe we could have a function hook that defaults to pointing at the in-core computation, and then a module wanting to override that just gets into the hook. regards, tom lane