[10000truths]

Sounds like the goal here is to augment search with a sort of query language. One that's more structured than a mere list of keywords?

Ribbing aside, the "rethinking" here sounds a lot like an AI-specific spin on the "bring the code to the data, instead of data to the code" paradigm. I imagine that the same multitenancy caveats of allowing arbitrary user-defined queries against a relational database (execution limits, access controls, etc.) will apply here as well.

[esafak]

I don't understand why you wouldn't simply provide SQL with requisite security precautions. Do you really need more?

[10000truths]

SQL was designed with tabular data and a relational model in mind, and free-form documents have neither of those properties. You can shoehorn full-text search functionality into SQL - that's what the likes of MySQL/PostgreSQL/SQLite do - and it's good enough in cases where search isn't a core competency. But it's awkward to use and subject to the limitations of a syntax catered to declarative queries and rigid schemas.

[kaiokendev]

Google Search used to essentially be this, then they had to tack on finnicky AI systems to handling the parsing of unstructured queries, and that was a cost/time sink that swung the pendulum over to fully AI-native search. This is the pendulum swinging back the other way with a new generation of UX designers. And it'll swing back eventually, too.

[tomjakubowski]

A duckdb backend that can query something like Sourcebot would be swell.