Roel van Meer:
> > 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.
>
> In the proposed implementation, only the *original* input contributes to a
> result.
My question is no longer about virtual aliases, but about how the
proposed feature should work. This is not about slowing you down.
I am trying to understand how to make this feature more useful.
If someone specifies multiple maps, each map is given the same
query. When only some of the maps produce a result, what should
the final result be:
- The result is "not found". This is may be desirable in some cases.
Right now, the virtual(8) daemon queries three parallel tables
for mailbox file name, uid and gid; it can't deliver mail unless
all three are available. Maybe this will allow us to avoid
introducing more parallel lookups in the future.
- The result contains empty fields for unavailable results. I have
difficulty imagining where this would be desirable. Postfix
currently has no concept of "tuples of results", and therefore
has no concept that different tuple members might have different
meanings. Again, the nearest thing is the virtual(8) daemon.
- The result is a concatenation of the available results, without
indication of what maps produce "not found". I think this is what
the current patch does, and this is OK for current Postfix.
The result remains "not found" when all maps produce "not found".
If there is no one answer that covers all possible use cases, then
the behavior in the proposed patch would still be a good default.
Making it configurable can be done later.
I am getting close to implementing {} for grouping options and for
quoting arguments, because splitting on space/comma does not always
work well. This would allow more natural main.cf syntax such as:
pipemap:{map_1, ... ,map_n}, join:{map_1, ..., map_n}{options},
master.cf entries with -o {parameter = value}, options to specific
milters, and so on.
Remotely related to this is my note about "beefing up Postfix macro
processing" on the postfix-devel list.
Wietse
