The specific way of handling dynamic sql via stored procedures varies depending upon what flavor of sql you are using, but they boil down to eval'ing statments inside of the procedures or if-else blocks. Be forewarned, though, that eval'ing inside of stored procedures causes a performance hit.

To get the most optimal performance, though, it would be best to eliminate the dynamism, if you can do so w/o creating a mess. If your dynamic cases really boil down to a manageable set of statments, then it would probably be best to write/generate separate procs for each!

If, for example, the following Perl/SQL stement:

my $statment = "SELECT COL_1, COL_2 FROM $table";

is really only ever going to give you three SQL statments:

SELECT COL_1, COL_2 FROM TABLE_1
SELECT COL_1, COL_2 FROM TABLE_2
SELECT COL_1, COL_2 FROM TABLE_3
[download]

then you may be better off creating three procs (pseudo-SQL follows):

CREATE PROC get_stuff_table1 AS
  SELECT COL_1, COL2 FROM TABLE1;
CREATE PROC get_stuff_table2 AS
  SELECT COL_1, COL2 FROM TABLE2;
CREATE PROC get_stuff_table3 AS
  SELECT COL_1, COL2 FROM TABLE3;
[download]

This can get really out of control, though, if you are going to end up many procs. If you are going to end up with more than a handfult then you should consider generating them. Of course, this process can be eased if you generate your procs with a nice language such as, oh... umm.. Perl.