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?
My first thought about it was that
select unnest('{1,2,3}');
would start failing. But it turns out it already does fail:
ERROR: function unnest(unknown) is not unique
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
ERROR: could not determine polymorphic type because input has type "unknown"
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.
> UNNEST, and ROWS FROM have more capabilities including WITH ORDINALITY
> than the json_array_elements-like functions do.
AFAICT, this is nonsense. We did not tie WITH ORDINALITY to UNNEST;
it works for any set-returning function.
regression=# select * from unnest(array[1,2,3]) with ordinality;unnest | ordinality
--------+------------ 1 | 1 2 | 2 3 | 3
(3 rows)
regression=# select * from jsonb_array_elements('["a","b","c"]'::jsonb) with ordinality;value | ordinality
-------+------------"a" | 1"b" | 2"c" | 3
(3 rows)
regards, tom lane