> 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
