From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Pavel Luzanov <p(dot)luzanov(at)postgrespro(dot)ru>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: doc - add missing documentation for "acldefault" |
Date: | 2018-09-19 15:18:58 |
Message-ID: | ba8b14d1-3902-ebbc-e5a4-0d51186b092f@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 09/19/2018 10:54 AM, Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)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:
<snip>
> 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.
> However, I don't object to documenting any function that has its
> own pg_description string.
Ok.
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
From | Date | Subject | |
---|---|---|---|
Next Message | Fred Pratt | 2018-09-19 15:27:23 | Re: Code of Conduct |
Previous Message | Fabien COELHO | 2018-09-19 15:17:05 | Re: Progress reporting for pg_verify_checksums |