I suggest we allow opting into this based on a configuration flag called search_expressions that lists the ways sourcegraph will try to interpret the queries that come in. It could for example be set to this
search_expressions: ["regular", "structural"]
meaning that all queries would be tried both as regular expressions and as structural (comby) expressions. The default would start as ["regular"] so users would see no change in the results unless they specifically ask for it. Once we gain enough confidence in this feature, we could change the default to be ["regular", "structural"].
The current implementation of comby is likely to require more time to run than regex-based searches running against zoekt. So, we could punt and use a longer timeout when structural searches are enabled, or implement this in terms of streaming (#3991). I suggest we implement it in terms of streaming since that will help us get rid of some other issues around timeouts while keeping the system as fast and stable as possible.
This is the first step towards #3890.
I suggest we allow opting into this based on a configuration flag called
search_expressions
that lists the ways sourcegraph will try to interpret the queries that come in. It could for example be set to thismeaning that all queries would be tried both as regular expressions and as structural (comby) expressions. The default would start as
["regular"]
so users would see no change in the results unless they specifically ask for it. Once we gain enough confidence in this feature, we could change the default to be["regular", "structural"]
.The current implementation of comby is likely to require more time to run than regex-based searches running against zoekt. So, we could punt and use a longer timeout when structural searches are enabled, or implement this in terms of streaming (#3991). I suggest we implement it in terms of streaming since that will help us get rid of some other issues around timeouts while keeping the system as fast and stable as possible.