Re: [HACKERS] Multi column range partition table
От | Amit Langote |
---|---|
Тема | Re: [HACKERS] Multi column range partition table |
Дата | |
Msg-id | 07e5a781-0168-0a03-4586-524cf2d1b2fd@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] Multi column range partition table (Dean Rasheed <dean.a.rasheed@gmail.com>) |
Ответы |
Re: [HACKERS] Multi column range partition table
|
Список | pgsql-hackers |
On 2017/07/07 4:55, Dean Rasheed wrote: > On 5 July 2017 at 18:07, Dean Rasheed <dean.a.rasheed@gmail.com> wrote: >> So if we were to go for maximum flexibility and compatibility with >> Oracle, then perhaps what we would do is more like the original idea >> of UNBOUNDED ABOVE/BELOW, except call them MINVALUE and MAXVALUE, >> which conveniently are already unreserved keywords, as well as being >> much shorter. Plus, we would also relax the constraint about having >> finite values after MINVALUE/MAXVALUE. >> > So I know that I have flip-flopped a few times on this now, but I'm > now starting to think that this approach, replacing UNBOUNDED with > MINVALUE and MAXVALUE is the best way to go, along with permitting > finite values after MINVALUE/MAXVALUE. Sure. > This gives the greatest flexibility, it's not too verbose, and it > makes it easy to define contiguous sets of partitions just by making > the lower bound of one match the upper bound of another. > > With this approach, any partition bounds that Oracle allows are also > valid in PostgreSQL, not that I would normally give too much weight to > that, but it is I think quite a nice syntax. Of course, we also > support things that Oracle doesn't allow, such as MINVALUE and gaps > between partitions. Agreed. MINVALUE/MAXVALUE seems like a good way forward. > Parts of the patch are similar to your UNBOUNDED ABOVE/BELOW patch, > but there are a number of differences -- most notably, I replaced the > "infinite" boolean flag on PartitionRangeDatum with a 3-value enum and > did away with all the DefElem nodes and the associated special string > constants being copied and compared. That's better. > However, this is also an incompatible syntax change, and any attempt > to support both the old and new syntaxes is likely to be messy, so we > really need to get consensus on whether this is the right thing to do, > and whether it *can* be done now for PG10. +1 to releasing this syntax in PG 10. The patch looks generally good, although I found and fixed some minor issues (typos and such). Please find attached the updated patch. Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
В списке pgsql-hackers по дате отправления: