> On Tue, Apr 07, 2026 at 01:02:49PM -0500, Sami Imseih wrote: > > Perhaps, but I don't see it being unreasonable for injection points. > > > > I guess we can also think about expanding InjectionPointCondition to > > handle other types of conditions, maybe OID??, to filter when running > > the point. > > Yeah, InjectionPointConditionType was designed with these types of > extensions in mind in terms of conditions you want to assign to a > point name when attaching it, with the check happening in the callback > attached when it is run. It should not be complicated to extend > injection_points_attach(), just pass down a string that it then > translated to an OID, or you could use a different grammar as well. > One thing that I'd be careful about is to handle that with one > argument in the SQL attach function, with the condition data given as > an input string. One grammar that Alexander K. designed at some point > for some of the facilities he had proposed was a JSON input, but > that's an implementation artifact. > > Doing something as a separate module/library would be also fine. We > do that for the AIO tests.
I think we can enhance these tests using a separate module as Daniil is suggesting, but we should probably get 0001 committed first and then have a quick follow-up. What do you think? -- Sami
