Re: [HACKERS] Multi column range partition table
От | Amit Langote |
---|---|
Тема | Re: [HACKERS] Multi column range partition table |
Дата | |
Msg-id | dcc50743-0cf1-a28c-a1a5-6add0ed80a76@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] Multi column range partition table (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Список | pgsql-hackers |
On 2017/07/03 14:00, Amit Langote wrote: > On 2017/07/03 2:15, Dean Rasheed wrote: >> On 30 June 2017 at 10:04, Ashutosh Bapat >> <ashutosh.bapat@enterprisedb.com> wrote: >>> On Fri, Jun 30, 2017 at 1:36 PM, Amit Langote >>> <Langote_Amit_f8@lab.ntt.co.jp> wrote: >>>> >>>> Alright, I spent some time implementing a patch to allow specifying >>>> -infinity and +infinity in arbitrary ways. Of course, it prevents >>>> nonsensical inputs with appropriate error messages. >>> >>> I don't think -infinity and +infinity are the right terms. For a >>> string or character data type there is no -infinity and +infinity. >>> Similarly for enums. We need to extend UNBOUNDED somehow to indicate >>> the end of a given type in the given direction. I thought about >>> UNBOUNDED LEFT/RIGHT but then whether LEFT indicates -ve side or +side >>> would cause confusion. Also LEFT/RIGHT may work for a single >>> dimensional datatype but not for multi-dimensional spaces. How about >>> MINIMUM/MAXIMUM or UNBOUNDED MIN/MAX to indicate the extremities. >>> >> >> Yes, I think you're right. Also, some datatypes include values that >> are equal to +/-infinity, which would then behave differently from >> unbounded as range bounds, so it wouldn't be a good idea to overload >> that term. > > Agree with you both that using (+/-) infinity may not be a good idea after > all. > >> My first thought was UNBOUNDED ABOVE/BELOW, because that matches the >> terminology already in use of upper and lower bounds. > > I was starting to like the Ashutosh's suggested UNBOUNDED MIN/MAX syntax, > but could you clarify your comment that ABOVE/BELOW is the terminology > already in use of upper and lower bounds? I couldn't find ABOVE/BELOW in > our existing syntax anywhere that uses the upper/lower bound notion, so > was confused a little bit. > > Also, I assume UNBOUNDED ABOVE signifies positive infinity and vice versa. Anyway, here's the revised version of the syntax patch that implements ABOVE/BELOW extension to UNBOUNDED specification. 0001 is the patch that Dean posted [1] as a replacement for what I earlier posted for simplifying range partition overlap check. 0002 is the UNBOUNDED syntax extension patch. Thanks, Amit [1] https://www.postgresql.org/message-id/CAEZATCVcBCBZsMcHj37TF%2BdcsjCtKZdZ_FAaJjaFMvfoXRqZMg%40mail.gmail.com -- 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 по дате отправления: