There is nothing wrong with a plpgsql function for anything a little more complex. The only situation where performance can suffer is when a plpgsql function is nested, because the query planner cannot further optimize the contained code in the context of the outer query which may or may not make it slower.
More details in this later answer:
This is much simpler than lots of CASE
clauses in a query:
CREATE OR REPLACE FUNCTION get_stuff(_param text, _orderby text, _limit int)
RETURNS SETOF stuff AS
$func$
BEGIN
RETURN QUERY EXECUTE '
SELECT *
FROM stuff
WHERE col = $1
ORDER BY ' || quote_ident(_orderby) || ' ASC
LIMIT $2'
USING _param, _limit;
END
$func$ LANGUAGE plpgsql;
Call:
SELECT * FROM get_stuff('hello', 'col2', 100);
Notes
Use RETURN QUERY EXECUTE
to return the results of query in one go.
Use quote_ident()
for identifiers to safeguard against SQLi.
Or format()
for anything more complex. See:
Pass parameter values with the USING
clause to avoid casting, quoting and SQLi once again.
Be careful not to create naming conflicts between parameters and column names. I prefixed parameter names with an underscore (_
) in the example. Just my personal preference.
Your second function after the edit cannot work, because you only return parent
while the return type is declared SETOF stuff
. You can declare any return type you like, but actual return values have to match the declaration. You might want to use RETURNS TABLE
for that.