To answer your question, it needs to be picked apart a little:
Does Select * from have the same performance implication
regarding wildcard interpretation
SELECT * has 3 main types of disadvantages:
- Code maintenance: using SELECT * reduces legibility for complex tables/queries, and can cause problems when a client application expects a certain result from a query, but the table changes
- Network performance: using SELECT * when returning results to a client application means that all columns will be returned to the client; if only some of those columns are used by the client, then bandwidth is wasted and the application runs slower than it could.
- Indexing / Query plan performance: Under some circumstances, if you have a query that really only needs to return the columns that participate in an index, but you return them all instead, then you could get much worse query plans created by the engine.
I'm not sure what you mean by "implication regarding wildcard interpretation", but I suspect you're misunderstanding why SELECT * is a bad idea - the SQL engine validates provided columns anyway; the cost of "expanding" the wildcard is essentially 0.
given that the stored procedure is a compiled unit of code
A stored procedure is not really a "compiled unit of code": the query plan for a stored procedure will usually be cached after it first runs, but the same is actually true of ad-hoc SQL statements also in many/most circumstances.
Now, to actually answer your question: Yes, any disadvantages of using SELECT * in ad-hoc SQL also apply, equally, to SQL inside of a stored procedure.
