Andrew Dunstan wrote
> Given that, I'm not sure we shouldn't permit them in b) either. I think
> I lost that argument back in the 9.2 dev cycle. I really don't want to
> get to a situation where foo::json::jsonb can produce an error.
So what do you propose happens when the input json has duplicate keys?
IMO A reasonable default cast function should error if the json contents
require anything more than a straight parse to be stored into jsonb. If the
user still needs to make the conversion we should have a standard and
configurable parser function with json input and jsonb output. In this case
the key-keep options would be "keep first encountered" or "keep last
encountered" or "fail on duplicate" the last of which would be the default.
I have not really pondered storing scalars into jsonb but before pondering
usability are there any technical concerns. If the goal is to share the
backend with hstore then current hstore does not allow for this and so the
json aspect would either transfer back over or it would need customized
code.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/additional-json-functionality-tp5777975p5779221.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
