Using the interpolated string handler with .FromSql is actually a bad idea, unless all of your parameters are ints / bools / simple types. It does essentially the same thing as AddWithValue.

More info: https://www.dbdelta.com/add...

Dan does not go over the addition danger of it causing plan cache bloat. Each time the sql is called with different sized parameters then it has to compile into a new execution plan. This causes memory bloat, and extra cpu time before the actual query is run.

I realize you were just trying to talk about Formatters, but talking about the SqlCommandInterpolatedStringHandler class without explaining the dangers might lead others to using it. I was very surprised when Microsoft added this without being able to specify maxlength / scale / precision for the parameters.

Thank you for your article.

I would say that for SQL Queries using the interpolated string handlers is a bit overkill, as the same result can be easily achieved using the classic FormattableString with much less code. It is actually what EF Core have been doing in its FromSqlInterpolated method for several years already. On the other hand, interpolated string handlers may still add some value if you add an additional parameter with CallerArgumentExpressionAttribute to AppendFormatted methods. This way it will be possible to use the variable names (with some additional escaping) instead of Param1, ..., ParamN.

I'm not sure if InterpolatedStringHandler can support CallerArgumentExpressionAttribute or not, given that those are two specialized C# operations that I'm not sure were designed to play nice together. It's an interesting idea, though.

As to overkill, it may be. This was primarily intended as example of what you can do. But I do believe it will be more performant than using FormattableString due to fewer allocations. Though, SqlCommand allocates and boxes a lot anyway, so the gain may be negligible.