Viktor Dukhovni:
> On Fri, Sep 12, 2014 at 11:36:18AM -0400, Wietse Venema wrote:
>
> > Viktor Dukhovni:
> > > On Fri, Sep 12, 2014 at 08:41:28AM +0200, Roel van Meer wrote:
> > >
> > > > Attached is the new patch. Sorry about the confusion.
> > > > This one has some documentation changes as well.
> > >
> > > Have not read the patch in detail. Quick note though, in databases
> > > "JOIN" is rather different from "UNION". The "pipemap" is a JOIN,
> > > your proposal is a UNION, and calling it "join" will cause confusion.
> >
> > Are you sure? The pipemap query becomes the input for the first
> > database query, then the first output becomes the input for the
> > second database query, and the last database query output becomes
> > the final result.
> >
> > The proposed feature joins multiple strings. It is similar to,
> > for example, the Perl and Python join() primitives, which implement
> > the inverse of their respective split() primitives.
> >
> > In database context, join means something different (compose one
> > table from multiple tables, based on a common key). The proposed
> > feature kind-of does that, no?
>
> With JOIN, you only get an answer when the key is present in all
> the tables.
That was a question that I had about the proposed implementation.
The current behavior loses information about which inputs do/don't
contribute to a result.
Wietse
