Hello,
>> 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:
The output of \df is one thing, but I was looking at pg online
documentation and hoping to find things as well.
\dfS returns nearly 3000 results, it is not really pratical unless you
already know what you are looking for, eg the name of the function...
>> I would strongly object to ignoring that policy in just one place.
>
> Ok, fair enough.
>
>> 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.
> Good idea -- I will take a look at that.
My initial complaint is that I did not know that there was an "acldefault"
function while I was looking for that kind of thing. ISTM that this one
should be kept explicitely in the doc.
I'm okay with documenting operators instead of the basic undelying
functions and skipping type management (in/out) functions, though.
--
Fabien.