Re: doc - add missing documentation for "acldefault"

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

In response to

Responses

Browse pgsql-hackers by date

  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