Shared label-filter matching for query paths (both engines).
Filter entries take the shapes produced by the PromQL parser and native HTTP params:
{key, "value"}— exact match{key, {:regex, pattern}}— anchored regex match{key, {:not_equal, "value"}}— negation{key, {:not_regex, pattern}}— anchored regex negation
Semantics follow Prometheus: a series that lacks the label is treated as
having the empty-string value, so label!="v" and label=~".*" match
series without the label, and label="" matches only series without it.
Invalid regex patterns match nothing (the query layer is expected to
reject them earlier).
Summary
Functions
Pre-compile the regex entries of a filter. Returns an opaque compiled
filter for match?/2.
Does a series' label map satisfy every entry of a compiled filter?
Build the strongest libSQL matcher JSON that is provably equivalent to a
necessary subset of label_filter.
Split a filter into {equality_map, complex_entries} where the equality
map contains only non-empty exact matches (safe to push down to storage
lookups keyed on present labels) and complex entries need match?/2
post-filtering.
Functions
Pre-compile the regex entries of a filter. Returns an opaque compiled
filter for match?/2.
Does a series' label map satisfy every entry of a compiled filter?
Build the strongest libSQL matcher JSON that is provably equivalent to a
necessary subset of label_filter.
The extension supports equality, inequality, and RE2-family regex matchers, while TimelessMetrics currently evaluates regular expressions with PCRE. Only a deliberately portable regex subset is pushed down. Unsupported patterns remain in the residual filter, so correctness never depends on a dialect guess. Duplicate matchers keep their full residual AND expression; one safe matcher may still narrow the storage candidates.
Returns :none when an invalid regex makes the complete filter impossible,
otherwise {extension_filter, residual_filter}.
Split a filter into {equality_map, complex_entries} where the equality
map contains only non-empty exact matches (safe to push down to storage
lookups keyed on present labels) and complex entries need match?/2
post-filtering.