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%'
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
