> perhaps typically querying a single underlying "database" with different
> queries/results for each "table".
Isn't that the case, when we configure postfix with mysql for example, and
create different tables for
virtual domains, virtual users and virtual aliases?
> Comma-separate everything. Whether from different rows, or different
> columns. The only time this is relevant in Postfix is email address lists.
Will do.
Regards
Hamid Maadani
June 17, 2022 9:46 PM, "Viktor Dukhovni" <postfix-us...@dukhovni.org> wrote:
> On Sat, Jun 18, 2022 at 02:45:26AM +0000, Hamid Maadani wrote:
>
>> I usually use client pools, because of their thread safety (which is not
>> needed here) as well as
>> the more aggressive cluster monitoring operations they have by default
>> compared to the single
>> threaded mongoc_client_t. There is no need to manually monitor the
>> connection and make sure
>> server has closed it when using mongoc_client_pool_t. That being said, I
>> have nothing against the
>> use of mongoc_client_t. Will convert to that.
>
> The client pool model could be justified, If you have a strong
> understanding of how a client pool would work in a process with
> potentially multiple open Postfix tables, perhaps typically querying a
> single underlying "database" with different queries/results for each
> "table".
>
> Postfix processes are single-threaded, so serialise all the queries, and
> if the database connection is reusable, and the pool is small, it could
> work well.
>
> Basically you want a "pool" of one connection per logical database
> reguardless of the query filter or result attributes. With ideally
> some reuse of that connection until idle long enough to drop it and
> start a new one.
>
>> Question about the result_attributes, how should multi-columned
>> multiple results be returned?
>
> Comma-separate everything. Whether from different rows, or different
> columns. The only time this is relevant in Postfix is email address
> lists.
>
>> For example, if 'result_attributes = username,password', for below
>> result set (filter = {"active":1}):
>> {"username":"hamid","password":"blah","active":1}
>> {"username":"wietse","password":"viktor","active":1}
>>
>> Should it return:
>>
>> hamid,blah,wietse,viktor
>
> It can only return a single string. So the above.
>
>> or:
>>
>> hamid,blah
>> wietse,viktor
>
> This makes no sense. There are no structured result sets, just
> single values or or comma-separated lists of email addreses.
>
> Don't forget to support expansion_limit (typically 1 if used),
> which would result in an error if more than one result would
> need to be output (comma-separated). Unlike LDAP, there's
> no recursion (no columns that are query URIs, triggering
> recursion) so no need for a recursion limit.
>
> --
> Viktor.
