Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-14474

INFORMATION_SCHEMA.CHECK_CONSTRAINTS

Details

    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)

      Attachments

        Issue Links

          Activity

            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 .

            vlads Vlad Skarzhevskyy added a comment - 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 .

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

            cvicentiu Vicențiu Ciorbaru added a comment - vlads The field length is probably an oversight, which we will fix in a subsequent push. Thanks for letting us know.
            anel Anel Husakovic added a comment - - edited

            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);
            
            

            anel Anel Husakovic added a comment - - edited 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);

            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.

            bar Alexander Barkov added a comment - 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.

            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.

            anel Anel Husakovic added a comment - 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.

            People

              anel Anel Husakovic
              serg Sergei Golubchik
              Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.