Re: [HACKERS] What's the point of json_extract_path_op etc?
Andrew Dunstan writes: > On 06/26/2014 03:11 PM, Tom Lane wrote: >> Do we actually want to document these things as both operators and >> functions? If we do, then the right answer is to list them as known >> exceptions in the opr_sanity test, not to hide the fact that we're >> violating the general documentation policy. > It's quite important that we have the variadic functions exposed. Yeah, I suppose --- and at this point backwards compatibility would demand it anyway. I'll go fix the regression test. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] What's the point of json_extract_path_op etc?
On 06/26/2014 03:11 PM, Tom Lane wrote: Andrew Dunstan writes: On 06/25/2014 02:46 PM, Tom Lane wrote: Why do we have essentially duplicate pg_proc entries for json_extract_path and json_extract_path_op? Likewise for json_extract_path_text_op, jsonb_extract_path_op, and jsonb_extract_path_text_op. ISTR trying that and running into problems, maybe with opr_sanity checks. Well, the reason that opr_sanity is complaining is that there's a violation of our general policy of documenting either the operator or the underlying function, not both. Using a separate pg_proc entry like this doesn't mean you didn't violate the policy; you just hid the violation from opr_sanity. Do we actually want to document these things as both operators and functions? If we do, then the right answer is to list them as known exceptions in the opr_sanity test, not to hide the fact that we're violating the general documentation policy. It's quite important that we have the variadic functions exposed. 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
Re: [HACKERS] What's the point of json_extract_path_op etc?
Andrew Dunstan writes: > On 06/25/2014 02:46 PM, Tom Lane wrote: >> Why do we have essentially duplicate pg_proc entries for json_extract_path >> and json_extract_path_op? >> Likewise for json_extract_path_text_op, jsonb_extract_path_op, and >> jsonb_extract_path_text_op. > ISTR trying that and running into problems, maybe with opr_sanity checks. Well, the reason that opr_sanity is complaining is that there's a violation of our general policy of documenting either the operator or the underlying function, not both. Using a separate pg_proc entry like this doesn't mean you didn't violate the policy; you just hid the violation from opr_sanity. Do we actually want to document these things as both operators and functions? If we do, then the right answer is to list them as known exceptions in the opr_sanity test, not to hide the fact that we're violating the general documentation policy. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] What's the point of json_extract_path_op etc?
On 06/25/2014 02:46 PM, Tom Lane wrote: Why do we have essentially duplicate pg_proc entries for json_extract_path and json_extract_path_op? The latter is undocumented and seems only to be used as the infrastructure for the #> operator. I see that only the former is marked variadic, but AFAIK the operator machinery couldn't care less about that, so it seems to me we could get rid of the json_extract_path_op entry and point the operator at json_extract_path. Likewise for json_extract_path_text_op, jsonb_extract_path_op, and jsonb_extract_path_text_op. ISTR trying that and running into problems, maybe with opr_sanity checks. But if you can get rid of them cleanly then by all means do. 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
[HACKERS] What's the point of json_extract_path_op etc?
Why do we have essentially duplicate pg_proc entries for json_extract_path and json_extract_path_op? The latter is undocumented and seems only to be used as the infrastructure for the #> operator. I see that only the former is marked variadic, but AFAIK the operator machinery couldn't care less about that, so it seems to me we could get rid of the json_extract_path_op entry and point the operator at json_extract_path. Likewise for json_extract_path_text_op, jsonb_extract_path_op, and jsonb_extract_path_text_op. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
