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.
