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.

Reply via email to