Re: [HACKERS] Multi column range partition table

On 17 July 2017 at 17:37, Dean Rasheed wrote: > On 17 July 2017 at 16:34, Robert Haas wrote: >> Do you want to own this open item, then? >> > OK. > > I need to give the patch another read-through, and then I'll aim to > push it sometime in the

Re: [HACKERS] Multi column range partition table

On 17 July 2017 at 16:34, Robert Haas wrote: > On Sun, Jul 16, 2017 at 6:40 AM, Dean Rasheed > wrote: >> Technically, anything that can be done using INCLUSIVE/EXCLUSIVE can >> also be done using using MINVALUE/MAXVALUE, by artificially adding >>

Re: [HACKERS] Multi column range partition table

On Sun, Jul 16, 2017 at 6:40 AM, Dean Rasheed wrote: > Technically, anything that can be done using INCLUSIVE/EXCLUSIVE can > also be done using using MINVALUE/MAXVALUE, by artificially adding > another partitioning column and making it unbounded above/below, but > that

Re: [HACKERS] Multi column range partition table

On 14 July 2017 at 06:12, Robert Haas wrote: > I agree that it's a big problem that (10, UNBOUNDED) > interpreted as a maximum value means first_column <= 10 and when > interpreted as a minimum value means first_column >= 10, because those > things aren't opposites of each

Re: [HACKERS] Multi column range partition table

On Sun, Jul 9, 2017 at 2:42 AM, Dean Rasheed wrote: > On 6 July 2017 at 22:43, Joe Conway wrote: >> I agree we should get this right the first time and I also agree with >> Dean's proposal, so I guess I'm a +2 > > On 7 July 2017 at 03:21, Amit

Re: [HACKERS] Multi column range partition table

On 12 July 2017 at 10:46, Ashutosh Bapat wrote: > On Wed, Jul 12, 2017 at 12:54 AM, Dean Rasheed > wrote: >> On 11 July 2017 at 13:29, Ashutosh Bapat >>> The description in this paragraph seems to be attaching intuitive >>> meaning of

Re: [HACKERS] Multi column range partition table

On Wed, Jul 12, 2017 at 12:54 AM, Dean Rasheed wrote: > On 11 July 2017 at 13:29, Ashutosh Bapat > wrote: >> + >> + Also note that some element types, such as timestamp, >> + have a notion of "infinity", which is just

Re: [HACKERS] Multi column range partition table

On 2017/07/12 4:24, Dean Rasheed wrote: > On 11 July 2017 at 13:29, Ashutosh Bapat > wrote: >> Most of the patch seems to be replacing "content" with "kind", >> RangeDatumContent with PartitionRangeDatumKind and RANGE_DATUM_FINITE >> with

Re: [HACKERS] Multi column range partition table

On 11 July 2017 at 13:29, Ashutosh Bapat wrote: > + > + Also note that some element types, such as timestamp, > + have a notion of "infinity", which is just another value that can > + be stored. This is different from MINVALUE and > +

Re: [HACKERS] Multi column range partition table

On Sun, Jul 9, 2017 at 1:12 PM, Dean Rasheed wrote: > On 6 July 2017 at 22:43, Joe Conway wrote: >> I agree we should get this right the first time and I also agree with >> Dean's proposal, so I guess I'm a +2 >> > > On 7 July 2017 at 03:21, Amit

Re: [HACKERS] Multi column range partition table

On Sun, Jul 09, 2017 at 08:42:32AM +0100, Dean Rasheed wrote: > On 6 July 2017 at 22:43, Joe Conway wrote: > > I agree we should get this right the first time and I also agree with > > Dean's proposal, so I guess I'm a +2 > > > > On 7 July 2017 at 03:21, Amit Langote

Re: [HACKERS] Multi column range partition table

On 6 July 2017 at 22:43, Joe Conway wrote: > I agree we should get this right the first time and I also agree with > Dean's proposal, so I guess I'm a +2 > On 7 July 2017 at 03:21, Amit Langote wrote: > +1 to releasing this syntax in PG 10. >

Re: [HACKERS] Multi column range partition table

On 7 July 2017 at 03:21, Amit Langote wrote: > The patch looks generally good, although I found and fixed some minor > issues (typos and such). Please find attached the updated patch. > Thanks for the review. Those changes all look good. I also see that I missed

Re: [HACKERS] Multi column range partition table

On 2017/07/07 4:55, Dean Rasheed wrote: > On 5 July 2017 at 18:07, Dean Rasheed 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

Re: [HACKERS] Multi column range partition table

On 2017/07/06 18:30, Dean Rasheed wrote: > On 5 July 2017 at 10:43, Amit Langote wrote: >> 0001 is your patch to tidy up check_new_partition_bound() (must be >> applied before 0002) >> > > I pushed this first patch, simplifying check_new_partition_bound() for >

Re: [HACKERS] Multi column range partition table

On 07/06/2017 01:24 PM, Dean Rasheed wrote: > On 6 July 2017 at 21:04, Tom Lane wrote: >> Dean Rasheed writes: >>> However, this is also an incompatible syntax change, and any attempt >>> to support both the old and new syntaxes is likely to be

Re: [HACKERS] Multi column range partition table

On 6 July 2017 at 21:04, Tom Lane wrote: > Dean Rasheed writes: >> 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

Re: [HACKERS] Multi column range partition table

Dean Rasheed writes: > 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

Re: [HACKERS] Multi column range partition table

On 5 July 2017 at 18:07, Dean Rasheed 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

Re: [HACKERS] Multi column range partition table

On 5 July 2017 at 10:43, Amit Langote wrote: > 0001 is your patch to tidy up check_new_partition_bound() (must be > applied before 0002) > I pushed this first patch, simplifying check_new_partition_bound() for range partitions, since it seemed like a good

Re: [HACKERS] Multi column range partition table

Hi Dean, On 2017/07/05 23:18, Dean Rasheed wrote: > On 5 July 2017 at 10:43, Amit Langote wrote: >> In retrospect, that sounds like something that was implemented in the >> earlier versions of the patch, whereby there was no ability to specify >> UNBOUNDED on a

Re: [HACKERS] Multi column range partition table

On 5 July 2017 at 10:43, Amit Langote wrote: > In retrospect, that sounds like something that was implemented in the > earlier versions of the patch, whereby there was no ability to specify > UNBOUNDED on a per-column basis. So the syntax was: > > FROM { (x [,

Re: [HACKERS] Multi column range partition table

On 5 July 2017 at 10:43, Amit Langote wrote: >> So the more I think about this, the more I think that a cleaner design >> would be as follows: >> >> 1). Don't allow UNBOUNDED, except in the first column, where it can >> keep it's current meaning. >> >> 2). Allow

Re: [HACKERS] Multi column range partition table

Hi Dean, On 2017/07/04 16:49, Dean Rasheed wrote: > On 3 July 2017 at 10:32, Amit Langote wrote: >> On 2017/07/03 17:36, Dean Rasheed wrote: >>> The bigger question is do we want this for PG10? If so, time is >>> getting tight. My feeling is that we do, because

Re: [HACKERS] Multi column range partition table

On 3 July 2017 at 10:32, Amit Langote wrote: > On 2017/07/03 17:36, Dean Rasheed wrote: >> The bigger question is do we want this for PG10? If so, time is >> getting tight. My feeling is that we do, because otherwise we'd be >> changing the syntax in PG11 of a

Re: [HACKERS] Multi column range partition table

Hi Dean, On 2017/07/03 17:36, Dean Rasheed wrote: > On 3 July 2017 at 06:00, Amit Langote wrote: >> On 2017/07/03 2:15, Dean Rasheed wrote: >>> My first thought was UNBOUNDED ABOVE/BELOW, because that matches the >>> terminology already in use of upper and lower

Re: [HACKERS] Multi column range partition table

On Mon, Jul 3, 2017 at 2:06 PM, Dean Rasheed wrote: > On 3 July 2017 at 06:00, Amit Langote wrote: >> On 2017/07/03 2:15, Dean Rasheed wrote: >>> My first thought was UNBOUNDED ABOVE/BELOW, because that matches the >>> terminology already

Re: [HACKERS] Multi column range partition table

On 3 July 2017 at 06:00, Amit Langote wrote: > On 2017/07/03 2:15, Dean Rasheed wrote: >> 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

Re: [HACKERS] Multi column range partition table

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 >> wrote: >>> On Fri, Jun 30, 2017 at 1:36 PM, Amit Langote >>> wrote: Alright, I spent some

Re: [HACKERS] Multi column range partition table

On 2017/07/03 2:15, Dean Rasheed wrote: > On 30 June 2017 at 10:04, Ashutosh Bapat > wrote: >> On Fri, Jun 30, 2017 at 1:36 PM, Amit Langote >> wrote: >>> >>> Alright, I spent some time implementing a patch to allow specifying >>>

Re: [HACKERS] Multi column range partition table

Hi Dean, Thanks a lot for the review. On 2017/07/03 1:59, Dean Rasheed wrote: > On 30 June 2017 at 09:06, Amit Langote wrote: >> When testing the patch, I realized that the current code in >> check_new_partition_bound() that checks for range partition overlap had

Re: [HACKERS] Multi column range partition table

On 30 June 2017 at 10:04, Ashutosh Bapat wrote: > On Fri, Jun 30, 2017 at 1:36 PM, Amit Langote > wrote: >> >> Alright, I spent some time implementing a patch to allow specifying >> -infinity and +infinity in arbitrary ways. Of

Re: [HACKERS] Multi column range partition table

On 30 June 2017 at 09:06, Amit Langote wrote: > When testing the patch, I realized that the current code in > check_new_partition_bound() that checks for range partition overlap had a > latent bug that resulted in false positives for the new cases that the new >

Re: [HACKERS] Multi column range partition table

On Fri, Jun 30, 2017 at 1:36 PM, Amit Langote 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

Re: [HACKERS] Multi column range partition table

On 2017/06/23 17:00, Dean Rasheed wrote: > On 23 June 2017 at 08:01, Ashutosh Bapat > wrote: >> The way we have designed our syntax, we don't have a way to tell that >> p3 comes after p2 and they have no gap between those. But I don't >> think that's your

Re: [HACKERS] Multi column range partition table

On 23 June 2017 at 08:01, Ashutosh Bapat wrote: > The way we have designed our syntax, we don't have a way to tell that > p3 comes after p2 and they have no gap between those. But I don't > think that's your question. What you are struggling with is a way to >

Re: [HACKERS] Multi column range partition table

On Fri, Jun 23, 2017 at 6:58 AM, Amit Langote wrote: > On 2017/06/22 20:48, amul sul wrote: >> Hi, >> >> While working on the another patch, I came across the case where >> I need an auto generated partition for a mutil-column range partitioned >> table having

Re: [HACKERS] Multi column range partition table

On 2017/06/23 13:42, amul sul wrote: > On Fri, Jun 23, 2017 at 6:58 AM, Amit Langote wrote: >> On 2017/06/22 20:48, amul sul wrote: >>> This happened because of UNBOUNDED handling, where it is a negative infinite >>> if it is in FROM clause. Wondering can't we explicitly treat this as >>> a

Re: [HACKERS] Multi column range partition table

On Fri, Jun 23, 2017 at 6:58 AM, Amit Langote wrote: > On 2017/06/22 20:48, amul sul wrote: >> Hi, >> >> While working on the another patch, I came across the case where >> I need an auto generated partition for a mutil-column range partitioned >> table having

Re: [HACKERS] Multi column range partition table

On 2017/06/22 20:48, amul sul wrote: > Hi, > > While working on the another patch, I came across the case where > I need an auto generated partition for a mutil-column range partitioned > table having following range bound: > > PARTITION p1 FROM (UNBOUNDED, UNBOUNDED) TO (10, 10) > PARTITION p2