From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: new json funcs |
Date: | 2014-01-11 00:16:58 |
Message-ID: | 19752.1389399418@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2014-01-11 00:18:06 | Re: Add CREATE support to event triggers |
Previous Message | Jim Nasby | 2014-01-11 00:14:46 | Re: Add CREATE support to event triggers |