Why not grandfather current users in at the current price and only increase the price for new users?

If you need to drop the price back down then drop the price for all existing users too. If you're charging monthly this is easy.

I always grandfather users. And it's easy when raising prices. The old users get to keep the old cheaper price and are happy.

I was referring to the difficulty when I:

1. Raise prices too high

2. Conversion rate and revenue is harmed, so I then revert to the lower price

3. I now have a bunch of old users paying a higher price, and they might be annoyed when they see the price has gone down. At a minimum I'd need to alter their payment plans to give them the new cheaper price in future

I guess it wouldn't be that difficult. Still, it wasn't long ago since the last price rise and for now I'd rather focus on growing and retaining the customer base.

Yes, alter the payment plan. Old users find out their subscription price has dropped -- that's a happy surprise not an annoyance. Assuming monthly billing. Yearly might be more complicated; perhaps extend the subscription length.

Yeah, this would be my recommendation as well. Others have taken this approach and it just makes people like you even more because they get to feel like early adopters who are being rewarded - and you actually then lose nothing at all.

With this I can consider switching back to iOS again.

Something else that provides a simple API for working with JSON in Postgres: https://github.com/robconery/massive-js (node.js)

That looks pretty awesome, although fairly orthogonal to this discussion. I submitted it as a story on its own. https://news.ycombinator.com/item?id=9407782

Write a function in PLV8?

Or Python, or any language that has a PL in PostgreSQL. Unfortunately a lot of people consider that a hack, and they're not wrong.

If we can address fields with operators (->, ->>, etc.) then why can't those operators modify, too? It works for everything else, after all. It's fairly counter-intuitive from a dev perspective.

That, and PLV8 still doesn't support JSONB. With JSONB being so much more efficient, faster, and so on, not being able to interact with it using the most logical procedural language is an EPIC oversight.

> If we can address fields with operators (->, ->>, etc.) then why can't those operators modify, too? It works for everything else, after all. It's fairly counter-intuitive from a dev perspective.

It certainly doesn't work for "everything else". You can update individual "parts" of arrays and record types, that's it. And those exception are hard-coded, so someone would either have to hard-code similar exceptions for JSON values (ugly, inflexible, generally a bad idea) or generalize support for custom operators on the left-hand side of assignments in UPDATE. All this while trying to push out a release which was already late by months.

You can call everything an oversight, but with very limited resources available and the need to cut a release at some point, this is far from the truth in this case.

Why is special-casting json or jsonb worse than special-casing arrays?

There have been calls to move toward jsonb, as well as a pull request for newer v8, but development seems to have stalled.

You can also write an update function in plain SQL. See my example in this comment on a recent plant postgresql post: http://bonesmoses.org/2015/04/10/pg-phriday-functions-and-ad...

currently, that is exactly how they are handled. the JSON structure is brought into memory, parsed, modified, and then written again to the database.

this is non-optimal, but currently the only method available.

That wouldn't change even if there was a specialized syntax, because of MVCC. So the only problem is that syntactic sugar is lacking, not that the performance isn't as good as it could be.

Brewing your own probiotics may be a safer option. People have been eating Sauerkraut for 1000s of years. I just add chopped cabbage and a tablespoon of salt into a quart-sized jar, fill with filtered water and wait a week or so until it tastes sour enough.