While preparing 3dfae91f7 I couldn't help noticing that what psql-ref.sgml has to say about \df's "function type" column:
... and function types, which are classified as <quote>agg</quote> (aggregate), <quote>normal</quote>, <quote>procedure</quote>, <quote>trigger</quote>, or <quote>window</quote>. no longer corresponds very well to what the code actually does, when dealing with a v11-or-later server: " CASE p.prokind\n" " WHEN 'a' THEN '%s'\n" " WHEN 'w' THEN '%s'\n" " WHEN 'p' THEN '%s'\n" " ELSE '%s'\n" " END as \"%s\"", ... /* translator: "agg" is short for "aggregate" */ gettext_noop("agg"), gettext_noop("window"), gettext_noop("proc"), gettext_noop("func"), gettext_noop("Type")); I was going to just fix the docs to match the code, but removing "trigger" from the list seems very confusing, because the docs go on to say To display only functions of specific type(s), add the corresponding letters <literal>a</literal>, <literal>n</literal>, <literal>p</literal>, <literal>t</literal>, or <literal>w</literal> to the command. and indeed filtering triggers in or out still seems to work. Moreover, if you are inspecting a pre-v11 server then you do still get the old classification, which is bizarrely inconsistent. It seems like we should either restore "trigger" as its own type classification, or remove it from the list of properties you can filter on, or adjust the docs to describe "t" as a special filter condition. I'm kind of inclined to the second option, because treating trigger as a different prokind sure seems like a wart. But back in 2009 people thought that was a good idea; what is our opinion now? regards, tom lane