On Tue, May 31, 2016 at 6:20 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> David Fetter <da...@fetter.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.
