On Wed, Apr 8, 2026 at 7:52 AM Sami Imseih <samimseih@gmail.com> wrote:
>
> > 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?
+1. I've pushed the fix.
It might also be useful if an injection point is activated on the
particular database rather than cluster-wide.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
