SQL note (3)-issues caused by temporary table name resolution lagging

The following functions are implemented in the stored procedure: tables of different structures are created based on different passing parameters.
Create proc testp
@ Var int
As
If @ Var = 1
Create Table # temp (K1 int identity, C1 INT)
Else
Create Table # temp (K1 int identity, C1 varchar (2 ))
Insert # temp default values
Select C1 from # temp
Go

Note: This process cannot be correctly executed. In the same stored procedure, SQL server does not allow multiple CREATE TABLE statements in a given temporary table.

There are three implementation methods:
Method 1: Replace it with a permanent table to avoid the limitations of a temporary table.
Create proc testp
@ Var int
As
If @ Var = 1
Create Table tempdb .. temp (K1 int identity, C1 INT)
Else
Create Table tempdb .. temp (K1 int identity, C1 varchar (2 ))
Insert tempdb .. temp default values
Select C1 from tempdb .. temp
Go

Note: Since sql7.0, persistent table name resolution is supported, but temporary table name resolution is not supported. In a separate stored procedure, the same variable cannot be declared multiple times in an independent code unit (including a temporary table.

Method 2: Solutions for resolving temporary table lagging names
If object_id ('testp') is not null
Drop proc testp
Go

Create proc testp
@ Var int
As
Create Table # temp (K1 int identity)
If @ Var = 1
Alter table # temp add C1 int default 0
Else
Alter table # temp add C1 varchar (10) default 'zsls'
Insert # temp default values
Exec ('select K1, C1 from # temp ')
Go

Note: It is necessary to use dynamic SQL, because the newly added column is not immediately visible to the process of adding it. Forced to create and run a specific query string to access the newly added column by name.
Advantages: DDL and DML statements are used together. Therefore, when an insert statement is encountered (the mode information of the temporary table has changed since the original plan is formed), the execution plan of the process must be re-compiled. Any stored procedure for creating a temporary table and further processing it will cause the plan to be re-compiled, because when the first execution plan is created, the schema information of the table no longer exists.
Disadvantages: Because it changes this mode and then processes the table, this process causes an additional re-compilation, when the execution plan is re-compiled, a compilation lock will be generated for the stored procedure, which will cause performance problems such as blocking and concurrency for large processes with high throughput.

Method 3: Roundabout measures for creating temporary tables
Create proc testp4
As
Insert # temp default values
Select C1 from # temp
Go

Create proc testp3
As
Create Table # temp (K1 int identity, C1 varchar (2 ))
Exec DBO. testp4
Go

Create proc testp2
As
Create Table # temp (K1 int identity, C1 INT)
Exec DBO. testp4
Go

Create proc testp
@ Var int
As
If @ Var = 1
Exec DBO. testp2
Else
Exec DBO. testp3
Go

Note: This method splits the original process into four independent processes, and CALLS process 4 from process 2 and process 3 in redundancy. The temporary table will be automatically deleted because it exceeds the scope, therefore, you must insert and select data in any process of creating a temporary table or in a public process called by them (the latter method is selected ). The object created in a process is visible to the process of calling it. Therefore, the 4th process can access the table created by its calling program (testp2, testp3.