On 01/10/2014 07:16 PM, Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
>> Tom Lane wrote:
>>> I wonder whether we should add an opr_sanity test verifying that operator
>>> implementation functions don't have their own comments? The trouble is
>>> that there are a few that are supposed to, but maybe that list is stable
>>> enough that it'd be okay to memorialize in the expected output.
>> +1. It's an easy rule to overlook.
> Here's a proposed addition to opr_sanity.sql for that:
>
> -- Show all the operator-implementation functions that have their own
> -- comments. This should happen only for cases where the function and
> -- operator syntaxes are equally preferred (and are both documented).
> -- Because it's a pretty short list, it's okay to have all the occurrences
> -- appearing in the expected output.
> WITH funcdescs AS (
> SELECT p.oid as p_oid, proname, o.oid as o_oid,
> obj_description(p.oid, 'pg_proc') as prodesc,
> 'implementation of ' || oprname || ' operator' as expecteddesc,
> obj_description(o.oid, 'pg_operator') as oprdesc
> FROM pg_proc p JOIN pg_operator o ON oprcode = p.oid
> WHERE o.oid <= 9999
> )
> SELECT p_oid, proname, prodesc FROM funcdescs
> WHERE prodesc IS DISTINCT FROM expecteddesc
> AND oprdesc NOT LIKE 'deprecated%'
> ORDER BY 1;
>
> In HEAD, this query produces
>
> p_oid | proname | prodesc
> -------+---------------------------+------------------------------------------------
> 378 | array_append | append element onto end of array
> 379 | array_prepend | prepend element onto front of array
> 1035 | aclinsert | add/update ACL item
> 1036 | aclremove | remove ACL item
> 1037 | aclcontains | contains
> 3947 | json_object_field | get json object field
> 3948 | json_object_field_text | get json object field as text
> 3949 | json_array_element | get json array element
> 3950 | json_array_element_text | get json array element as text
> 3952 | json_extract_path_op | get value from json with path elements
> 3954 | json_extract_path_text_op | get value from json as text with path elements
> (11 rows)
>
> The first five of these, I believe, are the cases I left alone back in
> commit 94133a935414407920a47d06a6e22734c974c3b8. I'm thinking the
> other six are the ones Andrew needs to remove the DESCR entries for.
>
>
Yeah, you just knocked out the last condition in the where clause, right?
Confirmed that when I do that and remove those DESCR entries we're left
with those 5 rows.
Is it better to knock out the DESCR entries totally or make them read
"implementation of foo operator"?
cheers
andrew