[MDEV-14474] INFORMATION_SCHEMA.CHECK_CONSTRAINTS Created: 2017-11-22  Updated: 2020-11-05  Resolved: 2018-08-25

Status: Closed
Project: MariaDB Server
Component/s: Information Schema
Fix Version/s: 10.3.10

Type: Task Priority: Major
Reporter: Sergei Golubchik Assignee: Anel Husakovic
Resolution: Fixed Votes: 0
Labels: beginner-friendly

Issue Links:
Relates
relates to MDEV-17323 Backport INFORMATION_SCHEMA.CHECK_CON... Closed
relates to MDEV-24139 CHECK_CLAUSE field in INFORMATION_SCH... Closed

 Description   

INFORMATION_SCHEMA.CHECK_CONSTRAINTS as in the standard (for GUI tools to be able to have all table metadata, e.g. for ALTER TABLE ... CHANGE)



 Comments   
Comment by Sergei Golubchik [ 2018-01-10 ]

In MariaDB check constraint names are not necessarily unique within a schema.
Let's extend the standard table with a column TABLE_NAME.

Comment by Sergei Golubchik [ 2018-01-10 ]

Alternative approach — add the column CHECK_CLAUSE to the existing INFORMATION_SCHEMA.TABLE_CONSTRAINTS table.

But it's somewhat against the standard logic, where TABLE_CONSTRAINTS only list names, while full constraint metadata is in CHECK_CONSTRAINTS for check, in CONSTRAINT_COLUMN_USAGE for unique and primary keys, and in REFERENTIAL_CONSTRAINTS for foreign keys.

Comment by Anel Husakovic [ 2018-03-29 ]

Hi serg I would like to work on this issue. Is it ok with you if I try to investigate it ?

Comment by Sergei Golubchik [ 2018-03-29 ]

of course! please, go ahead

Comment by Vlad Skarzhevskyy [ 2018-12-17 ]

Thanks for adding this feature this helps with DB migration.
Wondering why CHECK_CLAUSE is only varchar(64) the texts for more or less complex constraints will be truncated .

Comment by Vicențiu Ciorbaru [ 2019-01-31 ]

vlads The field length is probably an oversight, which we will fix in a subsequent push. Thanks for letting us know.

Comment by Anel Husakovic [ 2019-02-01 ]

The order of table fields should go:
CONSTRAINT_CATALOG ; CONSTRAINT_SCHEMA ; TABLE_NAME ; CONSTRAINT_NAME ; CHECK_CLAUSE
Will be added in `10.2`.
Regarding the 64 limitation,I found that `nchar` is fixed with `field_length / field_charset->mbmaxlen` used to create well formed string.
What could be done is to detect that we are using "CHECK_CLAUSE" field and to change the logic, instead of `field_charset->mbmaxlen` to send `length`?!

int Field_varstring::store(const char *from,uint length,CHARSET_INFO *cs)
{
  ASSERT_COLUMN_MARKED_FOR_WRITE_OR_COMPUTED;
  uint copy_length;
  String_copier copier;
 
  copy_length= copier.well_formed_copy(field_charset,
                                       (char*) ptr + length_bytes,
                                       field_length,
                                       cs, from, length,
                                       field_length / field_charset->mbmaxlen);

Comment by Alexander Barkov [ 2019-02-11 ]

anel Please try to avoid putting workarounds like this:

detect that we are using "CHECK_CLAUSE" field and to change the logic, instead of `field_charset->mbmaxlen` to send `length`

into Field_varstring::store(). This will pollute the code.

Instead, you need to create a Field of a proper data type. Maybe TEXT.
Thanks.

Comment by Anel Husakovic [ 2019-02-18 ]

Hi bar,
thank you for letting me know how to proceed, I definitely learned something new
Here is a patch to solve this:
https://github.com/MariaDB/server/commit/eff1c437f24fa24d17b58283670a95a5d8807271
This patch is applied as new commit to PR #1127 and PR #1150 which are waiting to be merged.
Thanks.

Generated at Thu Feb 08 08:13:50 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.