I'm sure something like that will be added. One of the issues there facing is that hstore is a string => string map, so a conversion from json to that will be lossy (i.e. 'that "true" in hstore, is that the string "true" or a converted boolean true from json?').
What you can do right now though is use PL/V8 to query the JSON fields. Then you can use functional indexes to still being able to speed up queries. Yes. You could that before but now there's a guarantee that a field of type json contains just that, meaning that your application logic will get simpler.
You won't get them in an hstore[0] column, which was the context of my reply. Of course in a JSON column you want full JSON support, but my and my parent's post were about converting back and forth between hstore and json.
Since hstore only handles string:string mapping, the choice is either to silently corrupt data by stringifying all values in the json->hstore encoding, or erroring out if the input data is anything other than string:string.
The latter would be what I'd prefer, and more in line with usual Postgres behavior.
JSON is much more powerful than hstore. Not only can it store different JSON data types (boolean, numbers) but also you can store documents with multiple levels deep, which is not possible on the hstore type.
Having said that, hstore is perfect when storing simple key/values. It's been battle tested and used for years and has some powerful and native indexing possibilities.
hstore is much more limited, it's a flat mapping of strings to strings (so a single level of JSON object). And as I noted, there does not seem to be any convenience method for converting between hstore and JSON data (or the other way around)
