Hi, Nikita!
On Feb 08, Nikita Malyavin wrote:
On Tue, Feb 5, 2019 at 10:37 AM Sergei Golubchik <serg@mariadb.org> wrote:
as discussed, let's give the constraint the same name as the period. but don't forget to add a test where a user explicitly creates a constraint with this name. Like
create or replace table t (id int primary key, s date, e date, period for mytime(s,e), constraint mytime (id < 100));
Oh, I thought You meant to leave it as is. Ok, but what about making it not a CHECK constraint? I mean, to make its name not overlapping with CHECK constraints namespace. This will mean that the user can create his own CHECK constraint with the same name, and have no syntax to drop PERIOD constraint. What do you think about it?
I thought you've wanted it a CHECK constraint. You've quoted the standard proving your point of view.
I've also quoted that it's name shouldn't match any existing constraint name:) So if to choose what to violate -- I'd choose the CHECK word, so adding a
diff --git a/sql/table.h b/sql/table.h
--- a/sql/table.h +++ b/sql/table.h @@ -1730,6 +1747,9 @@ class IS_table_read_plan; /** The threshold size a blob field buffer before it is freed */ #define MAX_TDC_BLOB_SIZE 65536
+/** number of bytes read by uint2korr and sint2korr */ +#define korr2size 2
No, that's silly. It's like #define TWO 2 Of course korr2size is 2. And korr3size is 3, and korr4size is 4.
Of course! That's the way to say "This variable was stored as a 2-byte tuple".
I mean, you didn't remove the magic number. It's still 2, and if you'd like to change it to be 3, for example, you'd still need to go and change the code everywhere.
Oh, so You're really thinking on such refactoring, to change the sizes of
Hi, Sergei! On Fri, Feb 8, 2019 at 2:18 AM Sergei Golubchik <serg@mariadb.org> wrote: period wouldn't harm any possible existing standard-conformant table metainfo types rapidly? Then that 👇makes sense:
#define fieldno_size 2 #define fieldno_korr uint2korr #define fieldno_store int2store
But I only care for self-documentation here. Besides, maybe it then shouldn't be fixed-size, but with unicode-like continuation marks? AFAIK current restriction is 4k columns per table, so there should be around four free bits. It will be even backwards compatible
That's why I suggested something like
#define fieldno_size 2 #define fieldno_korr uint2korr #define fieldno_store int2store
Oh no, that'll add 9 new macros! And the number can grow...
What do you mean, it's just three new macros, like above. Where's 9?
3 for fieldno, 3 for field_name_len, 3 for key_count (WITHOUT OVERLAPS commit), and who knows -- I've also planned an flag in FOREIGN KEY support.
-- Yours truly, Nikita Malyavin