-
Dmitry Lenev authored
With introduction of new data-dictionary in MySQL 8.0 SQL-layer can get all information about foreign keys from it using DD API. So it should be possible on SQL-layer to detect and emit error in situations when one tries to drop non-existing foreign key. However, this is still handled on SE level. This results in code redundancy between InnoDB and NDB SEs, akward code doing parsing of original ALTER TABLE statement in InnoDB SE and too generic error messages in some cases. This patch solves the problem by moving check that foreign key to be dropped exists from SEs to SQL-layer. It also removes corresponding checks from InnoDB and NDB SEs. As a side effect, the error code/message which is emitted in cases when one tries to drop non-existing foreign key from InnoDB table using ALTER TABLE executed through COPY algorithm is now more clear. Reviewed-by:
Sivert Sorumgaard <sivert.sorumgaard@oracle.com> Reviewed-by:
Lakshmi Narayanan Sreethar <lakshmi.narayanan.sreethar@oracle.com> Reviewed-by:
Debarun Banerjee <debarun.banerjee@oracle.com>
Dmitry Lenev authoredWith introduction of new data-dictionary in MySQL 8.0 SQL-layer can get all information about foreign keys from it using DD API. So it should be possible on SQL-layer to detect and emit error in situations when one tries to drop non-existing foreign key. However, this is still handled on SE level. This results in code redundancy between InnoDB and NDB SEs, akward code doing parsing of original ALTER TABLE statement in InnoDB SE and too generic error messages in some cases. This patch solves the problem by moving check that foreign key to be dropped exists from SEs to SQL-layer. It also removes corresponding checks from InnoDB and NDB SEs. As a side effect, the error code/message which is emitted in cases when one tries to drop non-existing foreign key from InnoDB table using ALTER TABLE executed through COPY algorithm is now more clear. Reviewed-by:
Sivert Sorumgaard <sivert.sorumgaard@oracle.com> Reviewed-by:
Lakshmi Narayanan Sreethar <lakshmi.narayanan.sreethar@oracle.com> Reviewed-by:
Debarun Banerjee <debarun.banerjee@oracle.com>
Loading