MDEV-33927 Wrong error message while altering the table with foreign key relationship

[Thirunarayanan]

• The Jira issue number for this PR is: MDEV-33927

Description

• Alter statement using copy algorithm throws wrong message "Cannot delete rows from table which is parent in a foreign key constraint" even though we expect duplicate key for the index.

copy_data_between_tables(): Remove the error condition to throw ER_FK_CANNOT_DELETE_PARENT and make sure that ALTER IGNORE shouldn't allow to break unique of foreign key constraints.

How can this PR be tested?

./mtr innodb.fk_col_alter

Basing the PR against the correct MariaDB version

• This is a new feature or a refactoring, and the PR is based against the latest MariaDB development branch.
• This is a bug fix, and the PR is based against the earliest maintained branch in which the bug can be reproduced.

PR quality check

• I checked the CODING_STANDARDS.md file and my PR conforms to this where appropriate.
• For any trivial modifications to the PR, I am ok with the reviewer making the changes themselves.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[dr-m]

Instead of explicitly specifying ALGORITHM=COPY, I think that we should add --enable_info around the ALTER TABLE statements in order to demonstrate that copy_data_between_tables was invoked on a nonempty table. With the native algorithm, we’d report "affected rows: 0". I do expect ALGORITHM=COPY to be used here, because the default is foreign_key_checks=1.

Because the code change affects ALTER IGNORE TABLE, I think that we should also cover the IGNORE variant here and display the contents of both tables after the operation.

ALTER IGNORE TABLE is a bit like "do what I mean" or "do the right thing": ambiguous, or meaning different things to different people or at different times. I am not a friend of that. I can imagine two expected outcomes here: One could be to rollback to a start-of-row savepoint so that no FOREIGN KEY constraint will not be violated and we just skip the offending row, like we do for duplicate key errors. Another one would be that ALTER IGNORE TABLE would fail with this particular error, with the reasoning that FOREIGN KEY constraints are more important than mere UNIQUE constraints.

I think that any change in behaviour needs to be mentioned in a test case comment.