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
