Thanks everybody. So based on the latest discussion I will:
1) rename the column from “Source code” to “Internal name”; and 2) change the contents to NULL except when the language (identified by oid) is INTERNAL or C.
Patch forthcoming, I hope.
I've attached a patch for this. It turns out to simplify the existing code in one way because the recently added call to pg_get_function_sqlbody() is no longer needed since it applies only to SQL functions, which will now display as a blank column.
I implemented the change and was surprised to see that no tests failed. Turns out that while there are several tests for \df, there were none for \df+. I added a couple, just using \df+ on some functions that appear to me to be present on plain vanilla Postgres.
I was initially concerned about translation support for the column heading, but it turns out that \dT+ already has a column with the exact same name so it appears we don’t need any new translations.
I welcome comments and feedback. Now to try to find something manageable to review.
If the form \df+ is used, additional information about each function is shown, including volatility, parallel safety, owner, security classification, access privileges, language, source code and description.