On Mon, May 23, 2016 at 4:37 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:

> Peter van Hardenberg <p...@pvh.ca> writes:
> > Great question, Marko. If you can point me towards an example I'll take a
> > look, but I'll proceed with the current understanding and suggestions and
> > see what people have to say.
> I believe Marko's just complaining about the case for unknown-type
> arguments, for example:
> regression=# select json_array_length('[1,2,3]');
>  json_array_length
> -------------------
>                  3
> (1 row)
> The parser has no trouble resolving this because there is only one
> json_array_length(); but if there were two, it would fail to make a
> determination of which one you meant.
> AFAICS the only way to fix that would be to introduce some preference
> between the two types.  For example, we could move both 'json' and 'jsonb'
> into their own typcategory ('J' is unused...) and then mark 'jsonb' as
> the preferred type in that category.  This would require a fair amount of
> experimentation to determine if it upsets any cases that work conveniently
> today; but right offhand I don't see any fatal problems with such an idea.
>                         regards, tom lane

​ guess the relevant point in the documentation is the parenthetical

(The processing functions consider the last value as the operative one.)

​Which normalizes the behaviors of jsonb and json as they pass through one
of these functions.  Though only the multi-key is noted which means
white-space (immaterial) and key-order (potentially material) behaviors
differ; though the later coming through the function unscathed is not
something that user's should be relying upon.  Specifically I'm thinking of
the behavior that "json_each(...)" would exhibit.

David J.

Reply via email to