Re: JSON[B] arrays are second-class citizens

On Tue, May 31, 2016 at 6:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> David Fetter <david(at)fetter(dot)org> writes:
> > On Tue, May 31, 2016 at 05:06:00PM -0400, David G. Johnston wrote:
> >> While likely not that common the introduction of an ambiguity makes
> >> raises the bar considerably.
>
> > What ambiguity?
>
> You get that as a result of the recent introduction of unnest(tsvector),
> which we debated a few weeks ago and seem to have decided to leave as-is.
> But it failed before 9.6 too, with
>
> So at least in this particular case, adding unnest(jsonb) wouldn't be a
> problem from the standpoint of not being able to resolve calls that we
> could resolve before.
>
> Nonetheless, there *is* an ambiguity here, which is specific to json(b):
> what type of array are you expecting to get? The reason we have both
> json[b]_array_elements() and json[b]_array_elements_text() is that there
> are plausible use-cases for returning either json or plain text. It's not
> hard to imagine that somebody will want json[b]_array_elements_numeric()
> before long, too. If you want to have an unnest(jsonb) then you will need
> to make an arbitrary decision about which type it will return, and that
> doesn't seem like an especially great idea to me.
>

​I'm on the fence given the presence of the tsvector overload and the lack
of any syntactic concerns.​

I would either have it keep the same form as our main unnest function:
<unnest(anyarray) : setof anyelement>

and/or have two functions

unnest(json, anyelement) : anyelement
unnest(jsonb, anyelement) : anyelement

The first one cannot fail at runtime (do to type conversion) while the
later two can.

If you can't tell I do like our introduction of what are basically Java
generics into our idiomatic json implementation.

​I'd call this implementing a better option for polymorphism than creating
a new function every time someone wants typed output.​

David J.