So all this time people have been telling me to use Postgres instead of MongoDB without the ability to edit fields in my documents? What other basic functionality is it missing?
Ideally you should be using Postgres or any other relational database instead of MongoDB for technical reasons other than document storage. (e.g. ACID)
Document storage in Postgres is a best-of-both-worlds approach (can store documents w/ ACID), with advantages of MongoDB and fewer downsides. But it's still relatively new functionality. (I've seen use cases of document storage for logging in-database and other quick-write/read-rarely data that would be a pain to normalize with consistent schema, which seems compelling)
Why not read its extensive documentation (http://www.postgresql.org/docs/9.5/static/), evaluate its capabilities vs. those of MongoDB with respect to your particular use case and decide for yourself?
SQL has never ever been meant for "editing documents", doing so is certainly not considered "basic functionality" for anyone whose use case is best served by a RDBMS, and you'll likely be displeased by the performance of such in Postgres (or any other RDBMS) if that is something you consider "basic functionality".
(FWIW: what I've found to be the typical use case of JSON-in-SQL (or XML-in-SQL) is that of storing opaque JSON or XML blobs generated by some external service, which could perhaps benefit from indexed lookups within this data. If you're designing your main SQL database around JSON you're probably doing something wrong.)
Other comments in the HN discussion indicate that 9.5 introduces an optimization to JSONB handling. It seems that you've always been able to edit fields in your documents, this just makes Postgres do less rewriting than before.
Document storage in Postgres is a best-of-both-worlds approach (can store documents w/ ACID), with advantages of MongoDB and fewer downsides. But it's still relatively new functionality. (I've seen use cases of document storage for logging in-database and other quick-write/read-rarely data that would be a pain to normalize with consistent schema, which seems compelling)