Re: [PATCH] Automatic HASH and LIST partition creation - Mailing list pgsql-hackers

From Rahila Syed
Subject Re: [PATCH] Automatic HASH and LIST partition creation
Date
Msg-id CAH2L28v_fmXvDF+UzMDCObgd7nuqSU=HAJPfw7w4TMx5HGv5ig@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Automatic HASH and LIST partition creation  (Anastasia Lubennikova <a.lubennikova@postgrespro.ru>)
Responses Re: [PATCH] Automatic HASH and LIST partition creation  (Anastasia Lubennikova <a.lubennikova@postgrespro.ru>)
List pgsql-hackers
Hi Anastasia,

I tested the syntax with some basic commands and it works fine, regression tests also pass.

Couple of comments: 
1. The syntax used omits the { IMMEDIATE | DEFERRED} keywords suggested in 
the earlier discussions. I think it is intuitive to include IMMEDIATE with the current implementation
so that the syntax can be extended with a  DEFERRED clause in future for dynamic partitions.
  CREATE TABLE tbl_lst (i int) PARTITION BY LIST (i)
 CONFIGURATION (values in (1, 2), (3, 4) DEFAULT PARTITION tbl_default);
 
2. One suggestion for generation of partition names is to append a unique id to
avoid conflicts.

3. Probably, here you mean to write list and hash instead of range and list as 
per the current state. 
     <para>
     Range and list partitioning also support automatic creation of partitions
      with an optional <literal>CONFIGURATION</literal> clause.
    </para>
 
4. Typo in default_part_name

+VALUES IN ( <replaceable class="parameter">partition_bound_expr</replaceable> [, ...] ), [( <replaceable class="parameter">partition_bound_expr</replaceable> [, ...] )] [, ...] [DEFAULT PARTITION <replaceable class="parameter">defailt_part_name</replaceable>]
+MODULUS <replaceable class="parameter">numeric_literal</replaceable>


Thank you,
Rahila Syed

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: __pg_log_level in anonynous enum should be initialized? (Was: pgsql: Change SHA2 implementation based on OpenSSL to use EVP digest ro)
Next
From: Bruce Momjian
Date:
Subject: Re: BUG #16419: wrong parsing BC year in to_date() function