On 09/19/2018 11:18 AM, Joe Conway wrote:
> On 09/19/2018 10:54 AM, Tom Lane wrote:
>> Joe Conway <mail@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:
>
> <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, so the attached version refactors/splits the group into two tables
-- operators and functions.
It drops aclinsert and aclremove entirely due to the fact that they no
longer do anything useful, to wit:
-----
Datum
aclinsert(PG_FUNCTION_ARGS)
{
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("aclinsert is no longer supported")));
PG_RETURN_NULL(); /* keep compiler quiet */
}
Datum
aclremove(PG_FUNCTION_ARGS)
{
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("aclremove is no longer supported")));
PG_RETURN_NULL(); /* keep compiler quiet */
}
-----
I also included John Naylor's patch with some minor editorialization.
Any further comments or complaints?
Thanks,
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development