Re: jsonb concatenate operator's semantics seem questionable

On 05/17/2015 05:56 PM, Peter Geoghegan wrote:
> On Sun, May 17, 2015 at 8:37 AM, Dmitry Dolgov <9erthalion6@gmail.com> wrote:
>> And I agree with thoughts above, that both concatenation modes ("simple" and
>> "deep") definitely can be useful. I can try to figure out how much work that
>> would be to modify the IteratorConcat function (or adapt Ilya's solution)
> I tend to think of it like this: jsonb more or less supports two use cases.
>
> Firstly, it supports the hstore use case, with a heterogeneous object
> stored in each row -- a hodge-podge of different attributes, which can
> be used to do something EAV-like, where there are application end user
> defined attributes, say. This is unlikely to involve any nesting,
> because we're only storing attributes of one entity (the row). This
> isn't the use of jsonb that people got excited about, and I think it's
> less important, although it does matter. The existence operator (which
> operates at the least nested level) is firmly about this use case. And
> for that matter, so is the new remove capability/minus operator thing
> (which also operates at the least nested level). Fine.
>
> The second use case is the "document database" use case, which is
> where jsonb is really compelling. Think of storing more or less fixed
> structure documents from a third party web API. Containment works in a
> nested fashion in support of that. And as I pointed out, not having
> the concatenate operator work in a nested fashion hobbles this use
> case. How are users supposed to write an SQL query that update's a
> single field in a nested object? That's obviously what they expect
> from this.
>
> I think it's misguided to make the concatenate operator target the
> hstore use case - if you have that use case, you're unlikely to have
> any nesting by convention anyway, and so it doesn't matter to you.
> Besides which, as I said, the "document database" use case is the one
> most users actually care about these days.
>

Peter,

Nobody is arguing that what you want isn't desirable. It just happens to 
be what we don't have. I get your disappointment, but you actually had a 
long time after the original patch was published to make your case. When 
I suggested 2 months ago to someone else that it was really too late to 
be adding this feature, nobody, including you, disagreed.

So what exactly do you want me or anybody else to do now, two days 
*after* we declared (not without pain) feature freeze?

If there is a consensus that what you want is so important that we need 
to implement the new behaviour at this late stage, I'm happy to spend 
time on it if there's a patch forthcoming. I might add that this should 
be an additional behaviour, since as Petr points out there is some 
validity to the current behviour.

If not, a function and operator can almost certainly be created with 
this behaviour as an extension for those who really need it in 9.5. I'm 
sure Dmitry will be happy to work on that.

cheers

andrew