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 next few days.
>
Committed.
Regards,
Dean
--
Sen
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
>> another partitioning column and making it unbound
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 would really just be a hack
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 other. I guess the prop
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 Langote wrote:
>> +1 to releasing this syntax in PG
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 word "unbounded" to MAXVALUE and MINVALUE, which have
>>> dif
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 another value that can
>> + be stored. This is different fr
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 PARTITION_RANGE_DATUM_VALUE. But those changes in name do
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
> + MAXVALUE, which are not real values th
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 Langote wrote:
>> +1 to releasing this syntax in
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 wrote:
> > +1 to releasing t
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.
>
So, that's 3 votes in favour of replacing UNBOUNDED
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 an example in the docs at the bot
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 them MINVALUE and MAXVALUE,
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
> range partitions, since it seemed
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 messy, so we
>>> really need to get consensus on whe
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 whether this is the right thing to do,
>> and whether
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 for PG10.
FWIW, I'd much
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 conveniently are already unreserved k
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 simplification, but note
that I don't th
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 per-column basis. So the syntax wa
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 [, ...]) | UNBOUNDED } TO { (y [, ...])
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 the partition bounds to have fe
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 otherwise we'd be
>>> changing the
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 feature only just released in PG10,
>
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 bounds.
>>
>> I was starting to li
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 in use of upper and lower bounds.
>>
>> I was starting to
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 suggested UNBOUNDED MIN/MAX syntax,
> bu
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 time implementing a patch to allow specifying
-infinity and +i
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
>>> -infinity and +infinity in arbitrary ways. Of course, it prevents
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 a
>> latent bug that resulted in
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 course, it prevents
>> nonsensical inputs with appropriate error mes
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
> less restrictive syntax allowed. I
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 -infinity and +infinity are the rig
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 question. What you are struggling with is
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
> specify a lower bound (10, +infinity)
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 following range bound:
>>
>> PARTITIO
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 positi
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 following range bound:
>>
>> PARTITIO
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
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 FROM (10, 10) TO (10, UNBOUNDED)
PARTITION p3 FROM
41 matches
Mail list logo
