On 01/10/2014 07:16 PM, Tom Lane wrote:
Alvaro Herrera <alvhe...@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%'

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.


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"?



Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to