On Thu, Dec 11, 2014 at 11:43 PM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
> In case of what we would have called a 'LIST' partition, this could look like
>
> ... FOR VALUES (val1, val2, val3, ...)
>
> Assuming we only support partition key to contain only one column in such a case.
>
> In case of what we would have called a 'RANGE' partition, this could look like
>
> ... FOR VALUES (val1min, val2min, ...) TO (val1max, val2max, ...)
>
> How about BETWEEN ... AND ... ?
Sure. Mind you, I'm not proposing that the syntax I just mooted is
actually for the best. What I'm saying is that we need to talk about
it.
> I am not sure but perhaps RANGE and LIST as partitioning kinds may as well just be noise keywords. We can parse those
valuesinto a parse node such that we don’t have to care about whether they describe partition as being one kind or the
other.Say a List of something like,
>
> typedef struct PartitionColumnValue
> {
> NodeTag type,
> Oid *partitionid,
> char *partcolname,
> Node *partrangelower,
> Node *partrangeupper,
> List *partlistvalues
> };
>
> Or we could still add a (char) partkind just to say which of the fields matter.
>
> We don't need any defining values here for hash partitions if and when we add support for the same. We would either
beusing a system-wide common hash function or we could add something with partitioning key definition.
Yeah, range and list partition definitions are very similar, but hash
partition definitions are a different kettle of fish. I don't think
we really need hash partitioning for anything right away - it's pretty
useless unless you've got, say, a way for the partitions to be foreign
tables living on remote servers - but we shouldn't pick a design that
will make it really hard to add later.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
