dovecot - Jul 2014 - solr_add_definite_query quotes queries

So Solr 4.0 and higher supports regular expressions in searching. However,
Dovecot is quoting search queries in solr_add_definite_query (via
solr_add_str_arg). This breaks regex searching. I do a sample search for emails
with "merged" in their body via the query /merg.*/. If you look at the
Solr logs, it is sending:
? q=body:"/merg.*/"
which is converted to body:\"/merg.*/\" inside Solr.


but if it had sent only:
? q=body:/merg.*/


then regex would have worked.

Is regular expression searching on the dashboard? I'm considering patching
fts-backend-solr.c to not quote-enclose the search, but am looking for any
better suggestions. Or perhaps not quote-enclose if the search is prefixed with
RX: (ie: "RX:/merg.*/")...


Thanks,
G H

On 31 Jul 2014, at 19:46, G H <uothrawn at yahoo.com> wrote:
> So Solr 4.0 and higher supports regular expressions in searching. However,
Dovecot is quoting search queries in solr_add_definite_query (via
solr_add_str_arg). This breaks regex searching. I do a sample search for emails
with "merged" in their body via the query /merg.*/. If you look at the
Solr logs, it is sending:
>   q=body:"/merg.*/"
> which is converted to body:\"/merg.*/\" inside Solr.
> 
> 
> but if it had sent only:
>   q=body:/merg.*/
> 
> 
> then regex would have worked.
> 
> Is regular expression searching on the dashboard? I'm considering
patching fts-backend-solr.c to not quote-enclose the search, but am looking for
any better suggestions. Or perhaps not quote-enclose if the search is prefixed
with RX: (ie: "RX:/merg.*/")...
I think if such feature is added it should definitely be optional and disabled
by default. Who knows what kind of problems users could cause by getting direct
access to that functionality. I guess the possibilities are to either have some
kind of a prefix (maybe that's the configurability,
fts_solr_passthrough_search_prefix=SOLR:) or maybe have a whole new search
parameter that specifies that this is now a direct Solr query (probably too much
trouble).