[shlomi-noach]

OP. I agree! RESTRICT is by far the best rule to use, and makes the most sense. Perhaps to balance my post a bit, and for what it's worth, I don't advocate for "don't ever use foreign keys" as a blanket statement. My experience was one where using foreign keys did not make sense. I do wish they were more operationally friendly.

[shlomi-noach]

Whoops. I wrote "OP" when I really meant "Post author". I'm a bit rusty with HN notations.

[_a_a_a_]

what does 'more operationally friendly' mean? TIA

[shlomi-noach]

Like the issues I mention in my post: modifying the data type of a column that is used by a foreign key; otherwise the fact you can't run Online DDL on a table that participates in foreign key relationship ; that INSTANT does not support (yet?) adding/removing foreign key constraints ; that cascaded writes are not written the the binary logs.

These are all things that the casual developer doesn't deal with when designing a schema and writes an app that INSERTs/DELETEs/UPDATEs to tables with foreign keys. But once there's a need for a change; once you wire 3rd party tools onto your database, that's where the operations hit a wall.

[_a_a_a_]

I didn't realise grep_it and you (shlomi-noach) were the same, apologies

[shlomi-noach]

We are not the same. My mistake for writing "OP".