Phil Rzewski
Phil Rzewski
The changes in #6052 have simplified this a bit since now the vectorized join is used in all circumstances, so the need for an explicit `sort` to guarantee stable output...
The current coverage of [`join` in the book docs draft](https://superdb.org/book/super-sql/operators/join.html) says plainly: > The output order of the joined values is undefined. This seems to set expectations appropriately. I've also...
In a group discussion about this one, I was reminded that while this isn't yet possible via record expressions, we did previously make this possible via `put` and `cut` (#4795),...
While we're waiting on this, @mccanne reminded me that something like this is possible today if you're ok adding the right-hand-side fields as an embedded record. Following on the example...
The Zed docs published in #2836 cited this issue as a current limitation. When this issue is addressed, the docs should be updated. A `join` test added in #2901 is...
The [Including the entire opposite record](https://zed.brimdata.io/docs/tutorials/join#including-the-entire-opposite-record) section of the [Join Tutorial](https://zed.brimdata.io/docs/tutorials/join) provides relevant detail for approaching this with the current implementation.
It looks like the new join implementation added in #5962 has the flexibility that provides the functionality originally sought here. ## Details Taking a step back, here's the input data...
In a group discussion it was pointed out that the challenge for us vs. the incumbent SQL solutions is that we don't have the luxury of always assuming values of...
In another review of this topic, short of the comprehensive "total order" fix, @mccanne acknowledged we might be able to fit in some targeted enhancements before the first GA SuperDB...
Linked PR #5886 contains an enhancement that somewhat improves the situation here by adding support for the string type. This is verified below in super commit d349e41 by repeating the...