Roel van Meer:
> 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.
>
> I can imagine that using the comma as delimiter is unwanted in such a
> generic part of postfix, but I had hoped that, since the higher layers
> are able to make sense of a comma separated string, that it would be
> possible for pipemap to do so as well.
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.
If the pipemap table were to always split the lookup result on
comma, then it would produce incorrect results for the vast majority
of Postfix maps, including canonical_maps, access maps, and so on.
That said, we could enable comma splitting via the pipemap syntax,
but the pipemap syntax was not meant to be extended:
pipemap (read-only)
A pipeline of lookup tables. Example: "pipemap:!type_1:name_1!
... !type_n:name_n". Each "pipemap:" query is given to the first
table. Each lookup result becomes the query for the next table
in the pipeline, and the last table produces the final result.
When any table lookup produces no result, the pipeline produces
no result. The first ASCII character after "pipemap:" will be
used as the separator between the lookup tables that follow (do
not use space, ",", ":" or non-ASCII).
Instead of changing the syntax we could use a different name and
call it pipemaps or spipemap (like pipemap, but split on '.').
Wietse
