Wietse Venema writes:
> That would be overkill. I had thought something like:
> - The first map returns a result;
> - The second maps splits this result by newline or comma, does a lookup for
> each of the keys, concats this back together, and passes it on as the new
> result.
That would break the vast majority of Postfix lookup tables.
Whether or not the lookup result will be split on comma depends on
where the result will be used. For example, virtual_alias_maps
splits the result on comma; most other Postfix maps don't.
Thanks for the explanation. I was indeed trying to use a pipemap in
virtual_alias_maps, hence the assumption about splitting results.
Instead of changing the syntax we could use a different name and
call it pipemaps or spipemap (like pipemap, but split on '.').
Well, while we're on the subject, this functionality is still only a
workaround for what I am trying to solve. In virtual_alias_maps, it would
only be different from the regular recursion if the first map would return
the lookup key as result.
What I am actually trying to do is a lookup with a single key in two
maps. Maybe stackmap or concatmap?
Now, if you specify two maps somewhere, and the first map returns a result,
there is no lookup done in the second map. With concatmap, both lookups
would happen, and the combined result would be returned.
Thinking about what you said, that still would only be useful in
virtual_alias_maps and not in most other Postfix maps. It would be nice to
have, but I don't know how common it is to have information in two different
maps.
Thanks again for your time,
Roel
