[Feature Request] Using InterpolatedStringHandler for templated command, becuase its pretty

Idea is simple, but i know there will be some pushback from people who scream SQL injection.

Im wrote my own micro ORM, there is outdated open source version here (this is link to relevant file): https://github.com/LittleNetworkHack/Crone/blob/main/Crone.Core/Components/Data/CoreDataCommandBuilder.cs

I use string builder for command text and dictionary to store parameters before converting it into ADO.NET provider specific command.
The way i use it is following:

public static void TestCommand(string ownerName, string viewName)
{
	CoreDataCommandBuilder command =
	$"""
	SELECT *
	FROM   ALL_VIEWS
	WHERE  OWNER = {ownerName}
	AND    VIEW_NAME = {viewName}
	""";

	var result = _provider.ExecuteDataTable(command);
}

This transalted into command text with placeholder and optionally (if bind by name) with name:

SELECT *
FROM   ALL_VIEWS
WHERE  OWNER = ~@ownerName
AND    VIEW_NAME = ~@viewName

Then ~@ is replace with provider specific binder like : for oracle.
Command from dictionary are added as parameters.

Pros:
Proper multiline command support
IDE highlight where parameters are actually places not just big orange text

Cons:
Idk, you tell me

Iterpolated string builder supports overloading for AppendFormatted types like integer, decimal, datetime...
I even handle int[] or string[] for SELECT * FROM TABLE WHERE ID IN ({array_parameter}) so i convert them into CSV value added directly into command text, this can be further sanitized if needed.

This is just idea, let me know what you think about it, i can go into more details about implementation if needed. Like support for formatting {DateTime.Now:YYYY-MM-DD} and RAW for actual SQL injection.

NOTE: ive built this before i saw EF Core doing something similar with execute raw sql, since i always wanted to write commands in a way that felt natural to me.

Start with the linked CoreDataCommandBuilder.cs and the issue's InterpolatedStringHandler example to understand the proposed command and parameter behavior. The issue has no agreed target or acceptance criteria, so clarify the API scope, parameter and array handling, formatting rules, and required SQL-injection safety before implementation.