Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 05/24/2015 05:38 PM, Tom Lane wrote: Andres Freund writes: On 2015-05-24 12:17:35 -0700, Peter Geoghegan wrote: Having gone to the trouble of making the parser support this stuff (in a way that makes us not follow the SQL standard in a couple of places), we ought to have a similar capabili

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

Andres Freund writes: > On 2015-05-24 12:17:35 -0700, Peter Geoghegan wrote: >> Having gone to the trouble of making the parser support this stuff (in >> a way that makes us not follow the SQL standard in a couple of >> places), we ought to have a similar capability for jsonb. I haven't >> looked

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 2015-05-24 12:17:35 -0700, Peter Geoghegan wrote: > Having gone to the trouble of making the parser support this stuff (in > a way that makes us not follow the SQL standard in a couple of > places), we ought to have a similar capability for jsonb. I haven't > looked into it, but it seems like a

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 05/24/2015 03:17 PM, Peter Geoghegan wrote: On Thu, May 21, 2015 at 2:25 PM, Andrew Dunstan wrote: This change really makes this set of jsonb features quite a bit more compelling. I'm glad I thought of it - wish I had done so earlier. So notwithstanding the controversy upthread, I think thi

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Thu, May 21, 2015 at 2:25 PM, Andrew Dunstan wrote: > This change really makes this set of jsonb features quite a bit more > compelling. I'm glad I thought of it - wish I had done so earlier. So > notwithstanding the controversy upthread, I think this is a good result. I think that we should l

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Fri, May 22, 2015 at 2:54 PM, Tom Lane wrote: >> I think there's essentially two scenarios for JSON usage; one where you >> want to be pretty paranoid about things like keys aren't missing, you're >> not trying to access a path that doesn't exist, etc. The other mode >> (what we have today) is

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 5/22/15 4:54 PM, Tom Lane wrote: Jim Nasby writes: On 5/22/15 2:44 PM, Andrew Dunstan wrote: Still I'd rather not add yet another parameter to the function, and I certainly don't want to make throwing an error the only behaviour. If instead of a create_missing boolean it accepted an enum

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

Jim Nasby writes: > On 5/22/15 2:44 PM, Andrew Dunstan wrote: >> Still I'd rather not add yet another parameter to the function, and I >> certainly don't want to make throwing an error the only behaviour. > If instead of a create_missing boolean it accepted an enum we could > handle both (since

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 5/22/15 2:44 PM, Andrew Dunstan wrote: On 05/22/2015 03:27 PM, Peter Geoghegan wrote: On Fri, May 22, 2015 at 11:59 AM, Andrew Dunstan wrote: As for raising an error, in principle it's doable, but the code to detect it might get messy. Also, I don't want a huge number of knobs. So I'm exci

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 05/22/2015 03:27 PM, Peter Geoghegan wrote: On Fri, May 22, 2015 at 11:59 AM, Andrew Dunstan wrote: As for raising an error, in principle it's doable, but the code to detect it might get messy. Also, I don't want a huge number of knobs. So I'm excited about the idea. I think that that's a

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Fri, May 22, 2015 at 11:59 AM, Andrew Dunstan wrote: > As for raising an error, in principle it's doable, but the code to detect it > might get messy. Also, I don't want a huge number of knobs. So I'm excited > about the idea. I think that that's a bad default behavior, although I don't think

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 05/22/2015 02:38 PM, Jim Nasby wrote: On 5/21/15 4:25 PM, Andrew Dunstan wrote: Here is a patch that renames jsonb_replace to jsonb_set with a boolean create_missing flag that defaults to false (should we default it to true?). With the flag set it's more or less upsert for jsonb. Without, it

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 5/21/15 4:25 PM, Andrew Dunstan wrote: Here is a patch that renames jsonb_replace to jsonb_set with a boolean create_missing flag that defaults to false (should we default it to true?). With the flag set it's more or less upsert for jsonb. Without, it's just update. I think upsert is probabl

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 05/21/2015 10:15 AM, Robert Haas wrote: On Wed, May 20, 2015 at 3:42 PM, Andres Freund wrote: On 2015-05-20 15:37:15 -0400, Tom Lane wrote: Josh Berkus writes: That does cover all bases, and users would be able to create the operator which suits their particular use case easily. It's al

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Wed, May 20, 2015 at 3:42 PM, Andres Freund wrote: > On 2015-05-20 15:37:15 -0400, Tom Lane wrote: >> Josh Berkus writes: >> > That does cover all bases, and users would be able to create the >> > operator which suits their particular use case easily. It's also fairly >> > similar to how jsqu

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 05/20/2015 03:37 PM, Tom Lane wrote: Josh Berkus writes: That does cover all bases, and users would be able to create the operator which suits their particular use case easily. It's also fairly similar to how jsquery works, although the syntax is completely different. But ... it's after fe

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 2015-05-20 15:37:15 -0400, Tom Lane wrote: > Josh Berkus writes: > > That does cover all bases, and users would be able to create the > > operator which suits their particular use case easily. It's also fairly > > similar to how jsquery works, although the syntax is completely different. > >

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

Josh Berkus writes: > That does cover all bases, and users would be able to create the > operator which suits their particular use case easily. It's also fairly > similar to how jsquery works, although the syntax is completely different. > But ... it's after feature freeze. So, thoughts? I thi

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

It is like bugfix than new feature Dne 20.5.2015 21:08 napsal uživatel "Josh Berkus" : > On 05/20/2015 11:34 AM, Andrew Dunstan wrote: > > So Dmitry, at my suggestion, has come up with a way of doing that, by > > adding a parameter to jsonb_replace(). If this parameter is set to true > > (it defau

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 05/20/2015 11:34 AM, Andrew Dunstan wrote: > So Dmitry, at my suggestion, has come up with a way of doing that, by > adding a parameter to jsonb_replace(). If this parameter is set to true > (it defaults to false) and the key or array element pointed to by the > last element of the path doesn't

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Wed, May 20, 2015 at 12:34 PM, Andrew Dunstan wrote: > > So Dmitry, at my suggestion, has come up with a way of doing that, by > adding a parameter to jsonb_replace(). If this parameter is set to true (it > defaults to false) and the key or array element pointed to by the last > element of the

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

Petr Jelinek wrote: > On 20/05/15 01:38, Jim Nasby wrote: > >If we get this wrong now, we'll be stuck with it forever. At a minimum I > >think we should use anything other than || until we can figure this out. > >That leaves || available for whichever case we decide on. > > I am of strong opinion

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 05/20/2015 02:11 AM, Peter Geoghegan wrote: On Tue, May 19, 2015 at 10:43 PM, Petr Jelinek wrote: I am of strong opinion that concat should be shallow by default. Again it's how jquery works by default, it's how python's dict.update works and you can find this behavior in other languages as

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Tue, May 19, 2015 at 10:43 PM, Petr Jelinek wrote: > I am of strong opinion that concat should be shallow by default. Again it's > how jquery works by default, it's how python's dict.update works and you can > find this behavior in other languages as well when dealing with nested > hashes. It's

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 20/05/15 01:38, Jim Nasby wrote: On 5/18/15 3:15 PM, Marko Tiikkaja wrote: On 2015-05-18 22:10, Josh Berkus wrote: On 05/18/2015 01:04 PM, Ryan Pedela wrote: In the context of splitting shallow and deep merge into two operators, I think + is better for shallow and || better for deep. The re

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 5/18/15 3:15 PM, Marko Tiikkaja wrote: On 2015-05-18 22:10, Josh Berkus wrote: On 05/18/2015 01:04 PM, Ryan Pedela wrote: In the context of splitting shallow and deep merge into two operators, I think + is better for shallow and || better for deep. The reason for + is because many programmin

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 05/18/2015 04:54 PM, David G. Johnston wrote: On Mon, May 18, 2015 at 12:12 PM, Josh Berkus >wrote: On 05/18/2015 11:58 AM, Peter Geoghegan wrote: > As you say, hstore isn't nested, and so this simply doesn't come up > there. We have failed to adopt "||"

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

Hello! [3] First of all few words about concatenation of jsonb values in my mind. Jsonb values concatenation result may follow this rules: 1) array of both values if both are scalars 2) concatenated array if both are arrays 3) prepended or appended array if only one is array 4) recursive concatena

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Mon, May 18, 2015 at 12:12 PM, Josh Berkus wrote: > On 05/18/2015 11:58 AM, Peter Geoghegan wrote: > > As you say, hstore isn't nested, and so this simply doesn't come up > > there. We have failed to adopt "||" to jsonb in a way that makes > > sense. We should have adopted it to jsonb in exact

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Mon, May 18, 2015 at 1:19 PM, Catalin Iacob wrote: > In hstore @> means unnested containment, in jsonb it means nested > containment. Therefore, when an hstore operator is applied to jsonb it gets > "nestedness" as jsonb is nested and adds that nestedness is an important > thing that sets it ap

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Mon, May 18, 2015 at 9:03 PM Andrew Dunstan wrote: > So you're arguing that we shouldn't call the operation in question || > because it's pretty much the same, mutatis mutandis, as the hstore > operation of the same name. You've lost me. > Hopefully this helps. Peter's argument, as I understa

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Mon, May 18, 2015 at 1:03 PM, Robert Haas wrote: > Realistically, as much as we might try to fool ourselves into > believing otherwise, operators are not self-documenting, except for > the ones you knew by the fourth grade. People will have to read the > documentation no matter what we do here

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 2015-05-18 22:10, Josh Berkus wrote: On 05/18/2015 01:04 PM, Ryan Pedela wrote: In the context of splitting shallow and deep merge into two operators, I think + is better for shallow and || better for deep. The reason for + is because many programming languages have this behavior. If I see th

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 05/18/2015 01:04 PM, Ryan Pedela wrote: > Let me back up a little. I always like to think about what is the ideal > interface first and then worry about implementation because > implementation can always be changed but interface can't. I think the > current concat/merge interface is the ideal. I

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Mon, May 18, 2015 at 12:24 PM, Josh Berkus wrote: > > On 05/18/2015 08:57 AM, Ryan Pedela wrote: > > If not, deep concatenation would solve this problem, but I can also see > > another solution. Use + for shallow concatenation since it really means > > "add element to top-level path" as Peter s

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Mon, May 18, 2015 at 3:21 PM, Peter Geoghegan wrote: > What is hard to understand about that? What is hard to understand is why you're going on and on about what is basically a matter of opinion after several people have said they don't agree with your opinion. Realistically, as much as we mi

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 05/18/2015 03:21 PM, Peter Geoghegan wrote: The only question worth discussing is whether we change the operator to "+" (or, for that matter, something else). I've seen your vote on this, so, does anyone else have an opinion on "+" vs. "||"? Preferably with a justification with some kind

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Mon, May 18, 2015 at 12:12 PM, Josh Berkus wrote: > OK, you've flagellated this deceased equine enough that I'm calling the > ASPCA. I get that you're unhappy that we don't have deep append. > Everyone gets this. I simply don't care; shallow append is better than > no append at all, and havin

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 05/18/2015 11:58 AM, Peter Geoghegan wrote: > As you say, hstore isn't nested, and so this simply doesn't come up > there. We have failed to adopt "||" to jsonb in a way that makes > sense. We should have adopted it to jsonb in exactly the same way as > the "@>" operator was. OK, you've flagell

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Mon, May 18, 2015 at 11:45 AM, Josh Berkus wrote: > On 05/18/2015 11:34 AM, Peter Geoghegan wrote: >> I'm not necessarily attached to "+". I just want to make this >> different to hstore's "||" operator. There should be a similar idiom >> with jsonb, but that can come later. > > This argument s

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 05/18/2015 02:45 PM, Josh Berkus wrote: On 05/18/2015 11:34 AM, Peter Geoghegan wrote: I'm not necessarily attached to "+". I just want to make this different to hstore's "||" operator. There should be a similar idiom with jsonb, but that can come later. This argument still makes no sense t

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 05/18/2015 11:34 AM, Peter Geoghegan wrote: > I'm not necessarily attached to "+". I just want to make this > different to hstore's "||" operator. There should be a similar idiom > with jsonb, but that can come later. This argument still makes no sense to me. Hstore is not nested. If anything,

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Mon, May 18, 2015 at 11:24 AM, Josh Berkus wrote: > On 05/17/2015 09:11 PM, Peter Geoghegan wrote:> As I said, I don't think > that my preference for deep concatenation is >> a matter of taste. I think that shallow concatenation is fundamentally >> and objectively at odds with what jsonb is sup

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Mon, May 18, 2015 at 11:16 AM, Andrew Dunstan wrote: > I could argue at least as convincingly that what the jsonb || operator does > is exactly analogous to what hstore's || does. Again, my concern is not primarily a theoretical one. It's primarily a practical concern. We are no closer to supp

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 05/17/2015 09:11 PM, Peter Geoghegan wrote:> As I said, I don't think that my preference for deep concatenation is > a matter of taste. I think that shallow concatenation is fundamentally > and objectively at odds with what jsonb is supposed to be (as long as > concatenation is the way "nested a

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 05/18/2015 01:43 PM, Peter Geoghegan wrote: On Mon, May 18, 2015 at 10:29 AM, Andrew Dunstan wrote: Having trouble scanning this. Since hstore isn't nested what the heck does "nested assignment" mean w.r.t. hstore? It means assigning to one "subdatum" in the hstore datum, as opposed to sim

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Mon, May 18, 2015 at 10:29 AM, Andrew Dunstan wrote: > Having trouble scanning this. Since hstore isn't nested what the heck does > "nested assignment" mean w.r.t. hstore? It means assigning to one "subdatum" in the hstore datum, as opposed to simply assigning an entirely new hstore (granted,

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 05/18/2015 01:18 PM, Peter Geoghegan wrote: So I think we should use the + operator to distance this from the hstore concatenate operator, which *is* widely understood to be mostly useful for "nested assignment". Having trouble scanning this. Since hstore isn't nested what the heck does

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Mon, May 18, 2015 at 5:05 AM, Andrew Dunstan wrote: > As between || and + I'm personally moderately indifferent. I think you're > representing some body of understanding about the effects of certain > operators as being widespread when that's very far from clear. > > You really still haven't sa

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

> creates the specified path if it does not exist. Does it? No, jsonb_replace() doesn't create an element, if it doesn't exist. I think, otherwise it can be confusing, so probably jsonb_add() may be more appropriate (and, actually, this function was already mentioned in previous discussions). On

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Mon, May 18, 2015 at 8:41 AM, Ryan Pedela wrote: > On Sun, May 17, 2015 at 9:41 PM, Josh Berkus wrote: > > Is there a particular reason why "+" makes more sense as "shallow >> concatination" and "||" makes more sense as "deep concatination"? Like, >> something in JS or other client languages

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Sun, May 17, 2015 at 9:41 PM, Josh Berkus wrote: > Is there a particular reason why "+" makes more sense as "shallow > concatination" and "||" makes more sense as "deep concatination"? Like, > something in JS or other client languages which would make that > preference make more sense to user

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 05/18/2015 12:11 AM, Peter Geoghegan wrote: On Sun, May 17, 2015 at 8:41 PM, Josh Berkus wrote: Is there a particular reason why "+" makes more sense as "shallow concatination" and "||" makes more sense as "deep concatination"? Like, something in JS or other client languages which would ma

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

18.05.2015, 06:41, Josh Berkus kirjoitti: > On 05/17/2015 05:46 PM, Robert Haas wrote: >> On May 17, 2015, at 8:38 PM, Peter Geoghegan wrote: >>> The current behavior does not seem acceptable for the concatenate >>> operator ("operator || jsonb"). >> >> I don't agree. It seems pretty clear to me

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Sun, May 17, 2015 at 8:41 PM, Josh Berkus wrote: > Is there a particular reason why "+" makes more sense as "shallow > concatination" and "||" makes more sense as "deep concatination"? Like, > something in JS or other client languages which would make that > preference make more sense to users

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 05/17/2015 05:46 PM, Robert Haas wrote: > On May 17, 2015, at 8:38 PM, Peter Geoghegan wrote: >> The current behavior does not seem acceptable for the concatenate >> operator ("operator || jsonb"). > > I don't agree. It seems pretty clear to me after reading the new posts that > the behavior

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Sun, May 17, 2015 at 5:46 PM, Robert Haas wrote: > On May 17, 2015, at 8:38 PM, Peter Geoghegan wrote: >> The current behavior does not seem acceptable for the concatenate >> operator ("operator || jsonb"). > > I don't agree. It seems pretty clear to me after reading the new posts that > the

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On May 17, 2015, at 8:38 PM, Peter Geoghegan wrote: > The current behavior does not seem acceptable for the concatenate > operator ("operator || jsonb"). I don't agree. It seems pretty clear to me after reading the new posts that the behavior is not an oversight, and that's enough for me to say

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Sun, May 17, 2015 at 3:22 PM, Andrew Dunstan wrote: > So what exactly do you want me or anybody else to do now, two days *after* > we declared (not without pain) feature freeze? As much as I'd like to just fix the concatenate operator, I really don't want to be the person that adds additional

Re: [HACKERS] 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 <9erthali...@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 modi

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Sun, May 17, 2015 at 8:37 AM, Dmitry Dolgov <9erthali...@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

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Sun, May 17, 2015 at 7:16 AM, Petr Jelinek wrote: > Agreed, if you look at jquery for example, the extend() method by default > behaves like our current || and you have to specify that you want deep merge > if you want the behavior described by Peter. So there is definitely point > for both, at

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

> Historical note: I think it's based on the nested hstore work, not on current hstore, but Dmitry can answer on that. Yes, you're right. 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

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 17/05/15 16:04, Andrew Dunstan wrote: On 05/16/2015 10:56 PM, Peter Geoghegan wrote: Another thing that I noticed about the new jsonb stuff is that the concatenate operator is based on the hstore one. This works as expected: postgres=# select '{"a":1}'::jsonb || '{"a":2}'; ?column?

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 05/16/2015 10:56 PM, Peter Geoghegan wrote: Another thing that I noticed about the new jsonb stuff is that the concatenate operator is based on the hstore one. This works as expected: postgres=# select '{"a":1}'::jsonb || '{"a":2}'; ?column? -- {"a": 2} (1 row) However, the nestin

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

> On May 16, 2015, at 10:56 PM, Peter Geoghegan wrote: > > Another thing that I noticed about the new jsonb stuff is that the > concatenate operator is based on the hstore one. This works as > expected: > > postgres=# select '{"a":1}'::jsonb || '{"a":2}'; > ?column? > -- > {"a": 2} > (1

[HACKERS] jsonb concatenate operator's semantics seem questionable

Another thing that I noticed about the new jsonb stuff is that the concatenate operator is based on the hstore one. This works as expected: postgres=# select '{"a":1}'::jsonb || '{"a":2}'; ?column? -- {"a": 2} (1 row) However, the nesting doesn't "match up" -- containers are not merged b