[tarantool-patches] Re: [PATCH 1/6] sql: move constraint name to struct contraint_parse

[n.pettik]

> On 17 Jan 2019, at 13:56, Konstantin Osipov <kostja at tarantool.org> wrote:
> 
> * n.pettik <korablev at tarantool.org> [19/01/16 23:09]:
>> struct constraint_parse {
>>        /** Name of table which constraint belongs to. */
>> -       struct SrcList *table_name;
>> +       struct SrcList *table;
>>        /** Name of the constraint currently being parsed. */
>>        struct Token name;
>> +       /**
>> +        * List of columns involved in constraint definition:
>> +        * indexed or referencing columns.
>> +        */
>> +       struct ExprList *cols;
> 
> Why not use constraint_def here and all future parser-specific
> objects? _def is our widely used abbreviation for "definition". A
> parser creates a constraint definition, and then it is used to
> create a runtime constraint object - struct constraint.

Do you suggest only rename this structure to constraint_def?
We don’t have constraint_def for the reason that every constraint
is stored in its own way: unique constraints as a part of indexes;
FK constraints are represented by fkey/fkey_def; check constraints
are stored as raw strings in space format. And they don’t have nothing
in common except for name (meanwhile in most cases it is
auto-generated name) and name of table they are related to.

If you suggest to use *for example* fkey_def instead of fkey_parse:
fkey_parse is used only within parser and contains parser specific
members: list of columns as they come from parser, indication of
self-referencing dependency etc.
I guess we are able to fit all these things in struct fkey_def, but is
it worth it? Note that fkey_parse is used ONLY during creation of FK,
other manipulations depend on fkey_def/fkey from struct space.

Also, see snippet in the second letter, mb it is exactly what you want.