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(at)dunslane(dot)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(at)dunslane(dot)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(at)dunslane(dot)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