On Thu, Dec 11, 2014 at 11:43 PM, Amit Langote
<langote_amit...@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 values into 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 be using 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
