Table name as a PostgreSQL function parameter

Don't do this.

That's the answer. It's a terrible anti-pattern. What purpose does it serve? If the client knows the table it wants data from, then SELECT FROM ThatTable! If you've designed your database in a way that this is required, you've probably designed it wrong. If your data access layer needs to know if a value exists in a table, it is trivially easy to do the dynamic SQL part in that code. Pushing it into the database is not good.

I have an idea: let's install a device inside elevators where you can type in the number of the floor you want. Then when you press "Go", it moves a mechanical hand over to the correct button for the desired floor and presses it for you. Revolutionary!

Apparently my answer was too short on explanation so I am repairing this defect with more detail.

I had no intention of mockery. My silly elevator example was the very best device I could imagine for succinctly pointing out the flaws of the technique suggested in the question. That technique adds a completely useless layer of indirection, and needlessly moves table name choice from a caller space using a robust and well-understood DSL (SQL) into a hybrid using obscure/bizarre server-side SQL code.

Such responsibility splitting through movement of query construction logic into dynamic SQL makes the code harder to understand. It destroys a perfectly reasonable convention (how a SQL query chooses what to select) in the name of custom code fraught with potential for error.

• Dynamic SQL offers the possibility of SQL injection that is hard to recognize in the front end code or the back end code singly (one must inspect them together to see this).
• At least in SQL Server, dynamic SQL executes with the privileges of the caller, not the running code. I wouldn't be surprised if PostgreSQL functioned the same way. This can render the entire application impervious to a reasonable change in security design, such as using stored procedures where the SP does things the caller had no permission for.
• When a developer must understand what the application code is doing in order to modify it or fix a bug, he'll find it very difficult to get the exact SQL query being executed. SQL profiler can be used, but this takes special privileges and can have negative performance effects on production systems. The executed query can be logged by the SP but this increases complexity for no reason (maintaining new tables, purging old data, etc.) and is totally non-obvious. In fact, some applications are architected such that the developer does not have database credentials, so it becomes almost impossible for him to actually see the query being submitted.

Here's a far better example in pseudo-C# of switching table names based on a parameter:

string sql = string.Format("SELECT * FROM {0};", escapeSqlIdentifier(tableName));
results = connection.Execute(sql);

Every flaw I have mentioned with the other technique is completely absent from this example.

Inside plpgsql code, The EXECUTE statement must be used for queries in which table names or columns come from variables. Also the IF EXISTS (<query>) construct is not allowed when query is dynamically generated.

Here's your function with both problems fixed:

CREATE OR REPLACE FUNCTION some_f(param character varying) RETURNS integer 
AS $$
DECLARE
 v int;
BEGIN
      EXECUTE 'select 1 FROM ' || quote_ident(param) || ' WHERE '
            || quote_ident(param) || '.id = 1' INTO v;
      IF v THEN return 1; ELSE return 0; END IF;
END;
$$ LANGUAGE plpgsql;

The first doesn't actually "work" in the sense that you mean, it works only in so far as it does not generate an error.

Try SELECT * FROM quote_ident('table_that_does_not_exist');, and you will see why your function returns 1: the select is returning a table with one column (named quote_ident) with one row (the variable $1 or in this particular case table_that_does_not_exist).

What you want to do will require dynamic SQL, which is actually the place that the quote_* functions are meant to be used.

I have 9.4 version of PostgreSQL and I always use this code:

CREATE FUNCTION add_new_table(text) RETURNS void AS
$BODY$
begin
    execute
        'CREATE TABLE ' || $1 || '(
        item_1      type,
        item_2      type
        )';
end;
$BODY$
LANGUAGE plpgsql

And then:

SELECT add_new_table('my_table_name');

It works good for me.

Attention! Above example is one of those which shows "How do not if we want to keep safety during querying the database" :P