On 6 April 2018 at 13:29, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > The selection of which functions to show can be further refined. > > I don't think the contents of pg_amproc and pg_cast should be excluded. > Some of those functions are useful. Similarly for pg_operator.oprcode. > > Things like oprrest and oprjoin will already be excluded because they > have "internal" arguments. Similarly for some columns in pg_aggregate.
You're right. There were lots of useful functions being excluded by the pg_amproc, pg_cast, and oprcode checks. And all the oprrest and oprjoin functions are already excluded, so I can remove that check. Perhaps we should remove the "appears in this catalog table" exclusion checks, and just use argument and return type? > There are also additional pseudo-types that should be excluded. See > pg_type.typtype = 'p', except some of those should not be excluded. > Needs more thought. I don't know much about some of the pseudotypes but this is what I propose: any*, record, _record, cstring should NOT be excluded void should NOT be excluded for return type (and perhaps in general; void_out and void_send are callable, if not hugely useful in psql) trigger, event_trigger should be excluded internal, opaque, unknown, pg_ddl_command should be excluded language_handler, tsm_handler, index_am_handler, fdw_handler should be excluded For modern servers, our query can be simplified to something like: SELECT distinct pg_catalog.quote_ident(p.proname) FROM pg_catalog.pg_proc p WHERE NOT arrayoverlap(ARRAY['internal', 'event_trigger', 'internal', 'opaque', 'unknown', 'pg_ddl_command', 'language_handler', 'tsm_handler', 'index_am_handler', 'fdw_handler']::regtype::oid, ARRAY(SELECT p.prorettype UNION SELECT unnest(proargtypes))); What do you think?