Thread: jsonb_delete not documented
The new function jsonb_delete does not appear to be documented. Is that intentional? The only thing that's documented is the #- operator for jsonb_delete_path. But jsonb_delete(jsonb, text) and jsonb_delete(jsonb, int) are not documented. (Those don't have an operator.)
Peter Eisentraut <peter_e@gmx.net> writes:
> The new function jsonb_delete does not appear to be documented. Is that
> intentional?
> The only thing that's documented is the #- operator for
> jsonb_delete_path. But jsonb_delete(jsonb, text) and
> jsonb_delete(jsonb, int) are not documented. (Those don't have an
> operator.)
Yeah they do ...
regression=# \df+ jsonb_delete List of
functions Schema | Name | Result data type | Argument data types | Type | Security | Volatility | Owner
|Language | Source code | Description
------------+--------------+------------------+---------------------+--------+----------+------------+----------+----------+------------------+------------------------------pg_catalog
|jsonb_delete | jsonb | jsonb, integer | normal | invoker | immutable | postgres | internal |
jsonb_delete_idx| implementation of - operatorpg_catalog | jsonb_delete | jsonb | jsonb, text |
normal| invoker | immutable | postgres | internal | jsonb_delete | implementation of - operator
(2 rows)
regression=# \do+ -
...pg_catalog | - | jsonb | integer | jsonb |
pg_catalog.jsonb_delete| delete array elementpg_catalog | - | jsonb | text
| jsonb | pg_catalog.jsonb_delete | delete object field
...
regards, tom lane
On 12/6/15 9:51 PM, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: >> The new function jsonb_delete does not appear to be documented. Is that >> intentional? > >> The only thing that's documented is the #- operator for >> jsonb_delete_path. But jsonb_delete(jsonb, text) and >> jsonb_delete(jsonb, int) are not documented. (Those don't have an >> operator.) > > Yeah they do ... > regression=# \do+ - > ... > pg_catalog | - | jsonb | integer | jsonb | pg_catalog.jsonb_delete| delete array element > pg_catalog | - | jsonb | text | jsonb | pg_catalog.jsonb_delete| delete object field > ... I see. The reference from pg_operator to pg_proc is by OID rather than function name, so I didn't find them. Is that because the function is overloaded? It's kind of odd that these are the only operators (at first glance) that are set up like that.
Peter Eisentraut <peter_e@gmx.net> writes:
> I see. The reference from pg_operator to pg_proc is by OID rather than
> function name, so I didn't find them. Is that because the function is
> overloaded?
Yeah, I suppose so --- regproc can't resolve overloaded function names.
> It's kind of odd that these are the only operators (at
> first glance) that are set up like that.
I think the customary thing when creating functions meant as operator
support is to give them unique names. These weren't done that way ...
I wasn't involved, but I wonder whether there was uncertainty as to
whether these should be documented as functions or operators.
regards, tom lane
On 12/06/2015 10:49 PM, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: >> I see. The reference from pg_operator to pg_proc is by OID rather than >> function name, so I didn't find them. Is that because the function is >> overloaded? > Yeah, I suppose so --- regproc can't resolve overloaded function names. > >> It's kind of odd that these are the only operators (at >> first glance) that are set up like that. > I think the customary thing when creating functions meant as operator > support is to give them unique names. These weren't done that way ... > I wasn't involved, but I wonder whether there was uncertainty as to > whether these should be documented as functions or operators. > > If we want to require that then perhaps we should have a check for it? I don't recall the exact reasoning so many months later, but you're probably right about how it came about. cheers andrew