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