> >> I see where you're coming from on that, but I don't think we can
> >> remove anything here in practice:
> >
> > Yes. Not unless we want to rely on the parser to track the lengths in
> > Const, which could be invasive, but I have not looked into it.
>
> Hmm. We may not want to get down to that, still that would be
> cheaper than reprocessing the parsing of the query string twice.
Although unless an extension, at least pg_stat_statements, should
not be doing this double work often, and if it is it is due to heavy
churn on entries.
> >> I still think it'd be reasonable for us to include
> >> ComputeConstantLengths in core to complete the picture of what we're
> >> doing with _jumbleElements and the length field already anyway. Its
> >> basically a way to fully hydrate the partially filled out JumbleState
> >> from the initial jumble.
> >
> > I fully agree, ComputeConstantLengths is an optional post-jumble-query step
> > for a consumer that wishes to calculate the lengths. The length calculation
> > is not unique to a plug-in, so in my mind the work it's doing is core
> > jumbling functionality.
>
> Okay. I could fall into that for this release. Marking the
> JumbleState as a const is the most important piece here.
I do agree.
> I'm +-0 regarding this routine, but I can also see your point about how it's
> useful to give at least the option to extensions to have a
> recomputation of the Const lengths, the same way as PGSS. What are
> the extensions that would use that?
https://github.com/search?q=fill_in_constant_lengths&type=code
A few well-known extensions/tools out there based on a Github search.
--
Sami
