I think you've answered your own question - it's not a great idea. Extension methods are useful in many cases for the sake of convenience, but semantic inconsistency/confusion outweights that here.
I completely agree with Noldorin but I would like to expand on his answer.
We use mappers in our code base and they all use an IMaper<TInput, TOutput> interface. We also used to have each of our mappers implement a MapAll method for mapping an input IEnumerable
to an output IEnumerable and each implementation was the same. The proposal was to create an extension method for the MapAll but the question was what object was it going to be an extension method for:
public IEnumerable<TOutput> MapAll<TInput, TOutput>(
this IEnumerable<TInput>, IMapper<TInput, TOutput>)
Or
public IEnumerable<TOutput> MapAll<TInput, TOutput>(
this IMapper<TInput, TOutput>, IEnumerable<TInput>)
Whilst they would both do the same job the first one would be really confusing as the MapAll method is only relevant in certain cases but it will always be present in your intelisense. where as the second approach whilst you may not need the MapAll method all the time it is clear as to what the purpose of the method is.
So to make your proposal work you could create an extension method for the IDbCommand interface which takes in a string instead (Excuse my attempt a VB.Net):
<Extension()> Function Execute(
ByRef con As IDbConnection, ByVal command as String) As Data.DataTable
...
End Function
And use it like so:
<%For Each dr In conn.Execute("select * from product").Rows%>
some HTML output here..
<%Next%>
I think the method name is unclear and should be something like GetDataTable but you can get an idea of what I mean.
If you want you can see my blog post on the mapper interface and extension method here to give you some context as to what I was on about.