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

From Fabien COELHO
Subject Re: [PATCH] Automatic HASH and LIST partition creation
Date
Msg-id alpine.DEB.2.22.394.2012221131410.533489@pseudo
Whole thread Raw
In response to Re: [PATCH] Automatic HASH and LIST partition creation  (Pavel Borisov <pashkin.elfe@gmail.com>)
Responses Re: [PATCH] Automatic HASH and LIST partition creation
List pgsql-hackers
HEllo.

>>> CREATE TABLE foo(a int) PARTITION BY LIST(a) CONFIGURATION (FOR VALUES
>> IN
>>> (1,2),(3,4) DEFAULT PARTITION foo_def);
>>
>> I would like to disagree with this syntactic approach because it would
>> very specific to each partition method. IMHO the syntax should be as
>> generic as possible. I'd suggest (probably again) a keyword/value list
>> which would allow to be quite adaptable without inducing any pressure on
>> the parser.
>>
> If I remember your proposal correctly it is something like
> CREATE TABLE foo(...) PARTITION BY HASH AUTOMATIC (MODULUS 10);

Yep, that would be the spirit.

> It is still possible but there are some caveats: 1. We'll need to add 
> keyword MODULUS (and probably AUTOMATIC) to the parser's list.

Why? We could accept anything in the list? i.e.:

    (ident =? value[, ident =? value]*)

> I don't against this but as far as I've heard there is some
> opposition among PG community against new keywords. Maybe I am wrong.

the ident is a keyword that can be interpreted later on, not a "reserved 
keyword" from a parser perspective, which is the only real issue?

The parser does not need to know about it, only the command interpreter 
which will have to interpret it. AUTOMATIC is a nice parser cue to 
introduce such a ident-value list.

> 2. The existing syntax for declarative partitioning is different to your
> proposal.

Yep. I think that it was not so good a design choice from a 
language/extensibility perspective.

> It is still not a big problem and your proposal makes query
> shorter for several words. I'd just like to see some consensus on the
> syntax. Now I must admit there are too many contradictions in opinions
> which make progress slow. Also I think it is important to have a really
> convenient syntaх.



> 2a Maybe we all who participated in the thread can vote for some variant?
> 2b Maybe the existing syntax for declarative partitioniong should be given
> some priority as it is already committed into CREATE TABLE ... PARTITION OF
> ... FOR VALUES IN.. etc.

> I'd be happy if everyone will join some version of the proposed syntaх in
> this thread and in the previous discussion [1]. If we have a variant with
> more than one supporter, sure we can develop patch based on it.
> Thank you very much
> and Merry Christmas!
>
> [1]
> https://www.postgresql.org/message-id/flat/alpine.DEB.2.21.1907150711080.22273%40lancre
>
>

-- 
Fabien.

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Confused about stream replication protocol documentation
Next
From: Bruce Momjian
Date:
Subject: Re: Proposed patch for key managment