How many engineers does it take to make subscripting work?

Whenever I&#x27;m adding a new table, I almost always try to add an &quot;internal_notes&quot; text field and a &quot;config&quot; JSONB field, no matter how static we think the data definition is going to be. Because at an early stage startup stage, you&#x27;re going to need to hack some fixes together. And given a choice between needing to QA a database migration vs. just adding {{foo.config.extra_whatever}} in a template, or using it in a single line of logic, the latter is just so much more feasible and easy-to-understand for a same-day bugfix, and you can always move to a dedicated column with a data migration later.<p>Of course, if you&#x27;re adding this to a few dozen rows, then you might need to jump into SQL to do this at scale. And then you run into the wonderful situations described in the article. I&#x27;ve had to write the following a great many times:<p><pre><code> config = jsonb_set(coalesce(config, &#x27;{}&#x27;::jsonb), &#x27;{&quot;some&quot;,&quot;key&quot;,&quot;path&quot;}&#x27;, to_jsonb(something::text)) </code></pre> Or this, which is great if you need to set a top-level key to something static; the || operator just mixes the two together similar to Object.assign:<p><pre><code> config = coalesce(config, &#x27;{}&#x27;::jsonb) || &#x27;{&quot;foo&quot;: &quot;bar&quot;}&#x27;::jsonb </code></pre> And honestly, the syntax, especially the second one, isn&#x27;t half bad once you get used to it. That said, the syntax from the article is amazing, and it will go a long way towards people reaching for Postgres even when their data model has a lot of unknowns.

I&#x27;m trying to understand this post, so I turned the initial &quot;problematic&quot; SQL into this:<p><pre><code> SELECT j-&gt;&#x27;k&#x27; FROM t; UPDATE t SET j = f(j, &#x27;{&quot;k&quot;}&#x27;, &#x27;&quot;v&quot;&#x27;); </code></pre> ... and the provided solution into this:<p><pre><code> SELECT j[&#x27;k&#x27;] FROM t; UPDATE t SET j[&#x27;k&#x27;] = &#x27;&quot;v&quot;&#x27;; </code></pre> I think I understand what a binary JSON column might be but by stripping variables and function names down to the minimum, both of these constructs look a bit heavy on the quotes and brackets (parenthesis.) There are squiggly brackets and square ones, single and double quotes. A lack of a colon is clearly an oversight.<p>I think I understand now: the function &quot;jsonb_set on a &quot;&#x27;@thing@&#x27;&quot; is to become a magic result by inference with enough syntax on a variable.<p>I think I may have some way to go before I achieve enlightenment 8)

The semantic difference between `jsonb_set` and the new subscripting syntax reminds me of ES6 arrow function situation: a new and improved syntax built seemingly to replace the old one, except there&#x27;s a slight semantic difference such that you sometimes still have to fall back to the old syntax for the specific effect. Not complaining, but just an additional quirk to have to teach beginners.

it reminds me<p><a href="https:&#x2F;&#x2F;ericlippert.com&#x2F;2003&#x2F;10&#x2F;28&#x2F;how-many-microsoft-employees-does-it-take-to-change-a-lightbulb&#x2F;" rel="nofollow">https:&#x2F;&#x2F;ericlippert.com&#x2F;2003&#x2F;10&#x2F;28&#x2F;how-many-microsoft-employ...</a>

The work looks awesome.<p>I am really really unconvinced that any teams should be reviewing patches by email like this when we have excellent PR-based workflows and interfaces. I know these people are 1000x better C programmers than me, but I think they are wrong and being unreceptive to improved technologies on this one.

why not this?<p>SELECT jsonb_column.key FROM table; UPDATE table SET jsonb_column.key = &#x27;&quot;value&quot;&#x27;;

&lt;2