On Tue, 31 Jan 2017 11:25:21 +
"Laurent Bercot" wrote:
> >This will prevent duplicates yes (which you don't mention on the
> >commit msg btw), however it doesn't actually change the return value
> >of ftrigr_update(), which is still the number of messages
> >processed.
>
> Duh. Sorry. Fi
This will prevent duplicates yes (which you don't mention on the commit
msg btw), however it doesn't actually change the return value of
ftrigr_update(), which is still the number of messages processed.
Duh. Sorry. Fixed.
--
Laurent
On Mon, 30 Jan 2017 17:01:31 +
"Laurent Bercot" wrote:
> There's no obvious way to make it more efficient without
> significantly exploding the amount of code, and we're talking about a
> scale where a bit
> of n^2 is completely negligible.
> I've committed a patch that does exactly what
There's no obvious way to make it more efficient without significantly
exploding the amount of code, and we're talking about a scale where a
bit
of n^2 is completely negligible.
I've committed a patch that does exactly what you suggested, even if
the code is organized a bit differently.
Ple
Save for errors, ftrigr_update() should return the number of ids for
which something happened, as the doc says, i.e. the length of the list
of ids.
So this is what the attached patch does.
Good catch, thanks.
I'm not convinced that there isn't a simpler or non-quadratic way of
handling this, t
Hi,
So I believe there's a (little) bug in ftrigr_update(). It has multiple
symptoms, but basically it boils down to: the list of ids
"returned"/made available can sometimes contain duplicates, and also
the return value might be wrong.
Imagine this: I subscribe w/ regex "[abc]" and option FTRIGR_
