The unionmap is available as of postfix-2.12-20140923.
unionmap:{map1, .., mapN} sends each query to all specified lookup
tables and concatenates all found results, separated by comma.
At its core this does the same thing as Roel's patch, but the user
interface reflects some recent improvements
Viktor Dukhovni writes:
> 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
On Mon, Sep 15, 2014 at 10:39:22AM -0400, Wietse Venema wrote:
> 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.
> Ri
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 long
Wietse Venema writes:
[join vs union]
I think there is something to be said for either name. It does not matter to
me, I think you should decide on a name, if you should choose to include
such functionality, to ensure it fits with Postfix's naming conventions
best.
That was a question
Viktor Dukhovni:
> 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
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 pa
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 f
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
Wietse Venema writes:
Unless I am mistaken, this implements the same functionality as the
pipemap table. It queries tables in sequence, not in parallel.
Attached is the new patch. Sorry about the confusion.
This one has some documentation changes as well.
Thanks,
Roel
Add support for joinmap
Wietse Venema writes:
Unless I am mistaken, this implements the same functionality as the
pipemap table. It queries tables in sequence, not in parallel.
You are correct. The patch consisted of three parts. The first two parts are
used to get the basic file structure in place for the joinma
Unless I am mistaken, this implements the same functionality as the
pipemap table. It queries tables in sequence, not in parallel.
Wietse
+static const char *dict_join_lookup(DICT *dict, const char *query)
+{
+const char myname[] = "dict_join_lookup";
+DICT_JOIN *dict_join = (DICT
Roel van Meer writes:
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,
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
On Wed, Sep 10, 2014 at 01:43:49PM -0400, Wietse Venema wrote:
> > Should it be "split on comma", or "parse as a list of addresses"?
>
> apipemap, then?
Sure, a pipeline of 1-to-n address mappings.
> Yes, the external/internal address form is a pain.
> The lookup keys should be in internal form
Viktor Dukhovni:
> On Wed, Sep 10, 2014 at 01:18:22PM -0400, Wietse Venema wrote:
>
> > Instead of changing the syntax we could use a different name and
> > call it pipemaps or spipemap (like pipemap, but split on ',').
>
> Should it be "split on comma", or "parse as a list of addresses"?
apipem
On Wed, Sep 10, 2014 at 01:18:22PM -0400, Wietse Venema wrote:
> Instead of changing the syntax we could use a different name and
> call it pipemaps or spipemap (like pipemap, but split on ',').
Should it be "split on comma", or "parse as a list of addresses"?
The latter is perhaps more correct i
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
Wietse Venema writes:
> > Would it be difficult to extend the pipemap functionality so it does a
> > lookup in the second map for each of the results produced by the first
> > map?
>
> Unfortunately, yes. The Postfix dictionary abstraction is a simple
> key->value service, and has no notion of
Viktor Dukhovni:
> On Wed, Sep 10, 2014 at 04:51:31PM +0200, Roel van Meer wrote:
>
> > Would it be difficult to extend the pipemap functionality so it does a
> > lookup in the second map for each of the results produced by the first map?
>
> Unfortunately, yes. The Postfix dictionary abstractio
On Wed, Sep 10, 2014 at 04:51:31PM +0200, Roel van Meer wrote:
> Would it be difficult to extend the pipemap functionality so it does a
> lookup in the second map for each of the results produced by the first map?
Unfortunately, yes. The Postfix dictionary abstraction is a simple
key->value serv
Hi everyone,
I have a question about the new pipemap functionality that is in the 2.12
experimental release.
If I chain two lookup tables, and the first produces multiple results, it
seems the lookup in the second table is done with all of the results at once.
That means that the pipemap
22 matches
Mail list logo
