Hi!
"Sergei" == Sergei Golubchik <sergii@pisem.net> writes:
Sergei> Hi, Sergei> we've talked about engine attributes in the CREATE TABLE, Sergei> and that one should be able to specify them per partition as well. Sergei> Now, thinking about it, I'm not quite sure what the semantics shuld be. Sergei> What is your use case ? How do you want them to work ? Sergei> I see different possibilities. Say, there is Sergei> create table ... (.....) XXX=1 Sergei> partition by list (a) Sergei> ( Sergei> partition p0 values in (1) YYY=2, Sergei> partition p1 values in (2) Sergei> ); Sergei> 1. We can say that XXX should be listed in the engine's hton-> table_options, and YYY - in the hton->partition_options. Sergei> this works fine because the engine can use table_share->option_struct Sergei> and it will contain correct values, independent from whether a table is Sergei> partitioned or not. Sergei> but it will break when partitioning will support different engines Sergei> in different partitions. Sergei> 2. We can say that XXX is partition engine options, and a pluggable Sergei> engine can only see YYY. YYY should come from hton->partition_options, Sergei> and the engine's table level attributes are not applicable. Sergei> The drawback - every engine needs to have special code to take care of Sergei> the partitioned case, and to duplicate all table-level options in the Sergei> partition-level options. Sergei> 3. Same as 2, but YYY can come from either table level or partition Sergei> level arrays. Every engine still needs the special code for partitioned Sergei> case, but does not need to duplicate the table_options array. For now I would suggest we go with 1), as this required least code from the engine sides. Reagards, Monty