Joe Conway <m...@joeconway.com> writes: > * I do believe aclitemeq() has utility outside internal purposes.
Our normal policy is that we do not document functions that are meant to be invoked through operators. The \df output saying that is sufficient: # \df+ aclitemeq List of functions Schema | Name | Result data type | Argument data types | Type | Volatility | Parallel | Owner | Security | Access privileges | Language | Source code | Description ------------+-----------+------------------+---------------------+------+------------+----------+----------+----------+-------------------+----------+-------------+------------------------------ pg_catalog | aclitemeq | boolean | aclitem, aclitem | func | immutable | safe | postgres | invoker | | internal | aclitem_eq | implementation of = operator (1 row) I would strongly object to ignoring that policy in just one place. Actually, it appears that most of these functions have associated operators: # select oid::regoperator, oprcode from pg_operator where oprright = 'aclitem'::regtype; oid | oprcode -----------------------+------------- +(aclitem[],aclitem) | aclinsert -(aclitem[],aclitem) | aclremove @>(aclitem[],aclitem) | aclcontains =(aclitem,aclitem) | aclitemeq ~(aclitem[],aclitem) | aclcontains (5 rows) So maybe what we really need is a table of operators not functions. However, I don't object to documenting any function that has its own pg_description string. regards, tom lane