Couldn't this be handled by having a new permission on FUNCTIONs
("CALL"?) to distinguish EXECUTE?
This would have to be made backwards-compatible, possibly by
automatically granting CALL ON ALL FUNCTIONS to public at schema create
time and/or PG upgrade time, which the schema owner could then REVOKE,
or by requiring CALL permission only functions marked PRIVATE.
Because initially a schema has no functions, the owner can revoke this
grant to public before creating any functions, thus there would be no
race contition. A race condition could be made less likely still by
having CALL not imply EXECUTE (users would have to have both to
successfully call a given function).
I would agree that a PRIVATE keyword would be a syntactically convenient
way to say that in its absence then public gets granted CALL on the
given function. But IMO it shouldn't be necessary, and either way
permissions machinery should be involved.
What do other SQL databases do? Does any have a PRIVATE keyword for
FUNCTIONs?
Using permissions has the net effect of making visibility more
fine-grained.
Regarding \df, I'm not sure that hiding function names one cannot call
is worthwhile, but if it were, then there are several options depending
on whether confidentiality of function names is to be a security
feature: RLS on the pg_catalog.pg_proc table (provides confidentiality),
or having a system view on it or filtering in psql (no real
confidentiality).
All that said, being able to have PRIVATE schemas, tables, views,
functions, FDWs, variables, maybe even roles, is definitly appealing,
mainly for code organization reasons.
I didn't understand how PRIVATE would help reduce the need for SECURITY
DEFINER. Can you explain?
Nico
--