Re: [HACKERS] Multi column range partition table - Mailing list pgsql-hackers

From Dean Rasheed
Subject Re: [HACKERS] Multi column range partition table
Date
Msg-id CAEZATCWjCn=eSGgbccMC6Oi7PqWfK1jBZNKvdVVs-JTJ5HMAwA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Multi column range partition table  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Responses Re: [HACKERS] Multi column range partition table
List pgsql-hackers
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.

My first thought was UNBOUNDED ABOVE/BELOW, because that matches the
terminology already in use of upper and lower bounds.

Regards,
Dean



pgsql-hackers by date:

Previous
From: Mithun Cy
Date:
Subject: Re: [HACKERS] Proposal : For Auto-Prewarm.
Next
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] Race-like failure in recovery/t/009_twophase.pl