David G. Johnston writes:
> Having the defined FK behaviors be more readily changeable, while not > mitigating this need, is IMO a more important feature to implement. If > there is a reason that cannot be implemented (besides no one has bothered > to take the time) then I would consider that reason to also apply to > prevent implementing this work-around. > > David J. I assume this would look something like: ALTER TABLE foo ALTER CONSTRAINT my_fkey ON UPDATE CASCADE ON DELETE RESTRICT with omitted referential_action implying preserving the existing one. Seems if we were going to tackle this particular problem, there would be two possible approaches here: 1) Change the definitions of the RI_FKey_* constraints for (at least) RI_FKey_*_del() to instead share a single function definition RI_FKey_del() and then pass in the constraint type operation (restrict, cascade, no action, etc) in as a trigger argument instead of having separate functions for each constraint type here. This would then ensure that the dispatch function could both change the constriant just by modifying the trigger arguments, as well as allowing for potential different behavior depending on how the underlying function is called. 2) Keep the existing RI trigger functions, but allow an ALTER CONSTRAINT variant to replace the trigger function to the new desired value, preserving (or transforming, as necessary) the original arguments. A few things off-hand: - pg_trigger locking will be necessary as we change the underlying args for the tables in question. This seems unavoidable. - partitions; do we need to lock them all in both solutions, or can we get away without it in the first approach? - with the first solution you would lose the self-describing name of the trigger functions themselves (moving to the trigger args instead); while it is a change in a very long-standing behavior/design, it *should* be an implementation detail, and allows things like the explicit DELETE [ RESTRICT | CASCADE ] the original patch was pushing for. - probably more I haven't thought of. Best, David
