Hi - > Are you sure the interface is correct?
Hard to be sure, so it's left generalized. The APIs would be unchanged if future search strategies are added (or subtracted); they'd affect the choice of acceptable KEY strings. We know we want glob patterns over executable file names. I've seen cases where an exact match query produces a different sqlite query plan from the glob one, but not sure how much performance difference that implies. Searching for source files by glob/match is removed from today's version because it doesn't run fast enough (without a new large index). > Is the sqlite "glob" pattern standardized? Yes. > Can it be provided if the underlying server database isn't sqlite? Yeah, in that unlikely case we undertake this someday. glob expressions can be translated to regular expressions, which are themselves supported in postgres & mysql. > I haven't read the whole diff yet. There are several refactorings > which would be nice to see a separate patch. One such part that occurs to me is the debuginfod_query_server() -> init_handles() / perform_queries() subdivision. Are there others? > Why does debuginfod-client.c use json-c? Can't the server sent the > json object as a normal char string? Why does the string from the > server need to be interpreted as a json object and then turned into a > string again? Use of the library allows robust processing (checking & merging) of incoming json data from multiple upstream servers. Luckily, json-c is a small & self-contained library. - FChE
