On Mon, Mar 30, 2026 at 02:20:47PM -0500, Sami Imseih wrote:
>> 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.
>> 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'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?
--
Michael
