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. You need LEFT JOIN to not lose rows. So I think of the proposal as more of a union of query results. Since Postfix ultimately flattens multi-row results into a single comma-separated value, the JOIN view is close, but I think not quite right. If Postfix in fact returned multiple result tuples, this would be more easily seen as a UNION. In a JOIN you get wide rows with some notion of table contributes results to each column, (horizontal multiplicity). With a union the tables are stacked vertically, with the column count not dependent on the number of tables being joined. We're down in the weeds though. Perhaps either will do, but I find union more intuitive in this context. -- Viktor.