Thanks! Unfortunately I'm not comfortable pulling this in due to breaking people's code. For example, I have seen SO answers using the "queryFormat" to alter the SQL (rather than purely inserting the values into the SQL), and of course our documentation in the README implies that "queryFormat" is always called, even when there are no values.

Perhaps there is another way to achieve the performance improvement you are trying to get? What is the performance different, anyhow?

I updated the changes so that the custom queryFormat function is always called, but SqlString.format is only called when needed. I also added benchmark results to the PR description. Just a heads up, the only way I could get the benchmark to finish without running out of memory was to comment out these two lines.

What if the guard was just directly added within the SqlString.format? Does that still have the same speedup? It would mean that the speed up extends to anyone using our format in any context (for example, using it within queryFormat).

I'm looking into addressing performance inside SqlString.format in a separate PR, but this PR still has merit. After running a benchmark, I was actually surprised to see that there is a noticeable performance difference between having the guard inside SqlString.format and having it outside:

Gotcha. I'm afraid for people who have overwritten SqlString.format , which is possible, they would break, and I'm just not confortable breaking them. I can hold this for when 3.0 comes, though.

By the way, if you have other changes, see if you can PR them this weekend if you would like to see them land in 2.11.0. I need to fix a bug introduced by one of these SqlString optimizations (not one of yours), and then master will be ready for 2.11, so just a heads up for anything else you want to include :)

Oh wow, I didn't think people would overwrite SqlString.format 😕
But if that's the case I'm totally fine with holding off on this until v3.0 👍

And I'll have a PR for SqlString.format out later today :)