Hello hackers, I'd like some feedback on a logical replication feature I would like to write a patch for.
The feature would allow users to register a custom conflict handler function to be executed for each conflicting row, after the built-in conflict resolver has run.
Running after the built-in conflict resolver allows the function to use the value provided by the resolver, for instance for custom logging.
The proposed programming model for the function follows the model for trigger functions - a set of read only variables are populated in the top-level block, and the function returns a record or NULL.
The conflict handler function would have more variables. At minimum, three records - the local version of the new value, the remote version of the new value, the value returned by the built-in resolver function - rather than the two for a trigger function, the timestamp information for the local and remote updates, the conflict type detected and the resolver used.
The new syntax proposed may look something like this:
CREATE SUBSCRIPTION <subname>
CONNECTION <conninfo>
PUBLICATION <pubname>
CONFLICT RESOLVER (conflict_type1 = resolver1 [, conflict_typeN = resolverN,... ])
[conflict_handler=my_custom_function]) // <--- allow users to pass a custom conflict resolution function.
Please let me know your thoughts, thanks!
Diego
