#1200 [Feature]: Support toggling `>=` incremental logic for SQL taps Issue created by pnadolny13 Feature scope Taps (catalog, state, stream maps, etc.) Description The Singer norm is to use

>=

when doing an incremental sync with a bookmark. Its for good reason but if someone knows they arent at risk of missing records using only

>

then we should allow it. I couldnt find where its documented but I know its to avoid ties that might have been missed on the last sync. For example if the bookmark is a date, and an incremental sync happens early on in the day, then more records arrive within that day, using

>

would skip those that arrive later in the day and the incremental sync wouldnt have worked as expected. So

>=

uses "at least once" semantics and requires deduping on the target end. The use case is for reverse ETL where the target cant handle dupes. Specifically Squared's target-apprise implementation posting to singer-ecosystem-activity in slack. There will always be < 5 records so ties are almost impossible and I think I'd honestly prefer the edge case to be not sending a record than sending it twice. In this case I'd like the option to override the default

>=

filter to use

>

. Another case is if someone uses an auto incrementing PK integer in a postgres database then theres no reason to be inclusive (although it has pretty minimal harm also), the user should have the preference if they know what theyre doing. I suggest we add something like

incremental_filter_inclusive

or

inclusive_filter

(names are tough 😄 ) that defaults to the status quo but allows us to override. Am I misunderstanding anything? meltano/sdk