Alvaro Herrera <> 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%'

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 
(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.

                        regards, tom lane

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to