Обсуждение: 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
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
Andrew Dunstan <andrew@dunslane.net> 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
On 06/26/2014 03:11 PM, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> 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
Andrew Dunstan <andrew@dunslane.net> 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