On Wed, Apr 8, 2026 at 7:52 AM Sami Imseih <[email protected]> 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
