Somehow the earlier patches missed qualifying pg_get_expr() by
pg_catalog. Fixed it along with annotating the partitioned partition
as ", PARTITIONED".
On Fri, Nov 3, 2017 at 6:09 PM, Alvaro Herrera wrote:
>>
>> Right now, we could do that if we order the list by bound expression;
>> lexically DE
On 2017/11/03 21:39, Alvaro Herrera wrote:
> Ashutosh Bapat wrote:
>> On Fri, Nov 3, 2017 at 1:42 PM, Alvaro Herrera
>> wrote:
>
>>> I think adding "is partitioned" at end of line isn't good; looks like a
>>> phrase but isn't translatable. Maybe add keyword PARTITIONED instead?
>>
>> In that ca
Ashutosh Bapat wrote:
> On Fri, Nov 3, 2017 at 1:42 PM, Alvaro Herrera
> wrote:
> > I think adding "is partitioned" at end of line isn't good; looks like a
> > phrase but isn't translatable. Maybe add keyword PARTITIONED instead?
>
> In that case may be we should separate bounds and "PARTITION
On Fri, Nov 3, 2017 at 1:42 PM, Alvaro Herrera wrote:
> Amit Langote wrote:
>> On 2017/09/06 19:14, Amit Langote wrote:
>> > On 2017/09/06 18:46, Rushabh Lathia wrote:
>> >> Okay, I have marked this as ready for committer.
>> >
>> > Thanks Ashutosh and Rushabh for rebasing and improving the patch.
Amit Langote wrote:
> On 2017/09/06 19:14, Amit Langote wrote:
> > On 2017/09/06 18:46, Rushabh Lathia wrote:
> >> Okay, I have marked this as ready for committer.
> >
> > Thanks Ashutosh and Rushabh for rebasing and improving the patch. Looks
> > good to me too.
>
> Patch needed to be rebased a
Thanks Amit for taking care of this.
On Wed, Sep 13, 2017 at 6:31 AM, Amit Langote
wrote:
> On 2017/09/06 19:14, Amit Langote wrote:
>> On 2017/09/06 18:46, Rushabh Lathia wrote:
>>> Okay, I have marked this as ready for committer.
>>
>> Thanks Ashutosh and Rushabh for rebasing and improving the
On 2017/09/06 19:14, Amit Langote wrote:
> On 2017/09/06 18:46, Rushabh Lathia wrote:
>> Okay, I have marked this as ready for committer.
>
> Thanks Ashutosh and Rushabh for rebasing and improving the patch. Looks
> good to me too.
Patch needed to be rebased after the default partitions patch we
On 2017/09/06 18:46, Rushabh Lathia wrote:
> Okay, I have marked this as ready for committer.
Thanks Ashutosh and Rushabh for rebasing and improving the patch. Looks
good to me too.
Regards,
Amit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your su
Okay, I have marked this as ready for committer.
Thanks,
On Wed, Sep 6, 2017 at 2:50 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> On Wed, Sep 6, 2017 at 1:06 PM, Rushabh Lathia
> wrote:
> >
> > 2) Add partition to the foo;
> >
> > create table foo_p1 partition of foo for value
On Wed, Sep 6, 2017 at 1:06 PM, Rushabh Lathia wrote:
>
> 2) Add partition to the foo;
>
> create table foo_p1 partition of foo for values in (1, 2, 3) partition by
> list (b);
>
> postgres=# \d foo
> Table "public.foo"
> Column | Type | Collation | Nullable | Default
> ---
I picked this patch for review and started looking at the implementation
details.
Consider the below test:
1)
postgres=# create table foo (a int, b int) partition by list (a);
CREATE TABLE
postgres=# \d foo
Table "public.foo"
Column | Type | Collation | Nullable | Default
---
On Mon, Sep 4, 2017 at 3:48 PM, Alvaro Herrera wrote:
>
> if (tuples > 0)
> {
> - if (tableinfo.relkind !=
> RELKIND_PARTITIONED_TABLE)
> - printfPQExpBuffer(&buf, _("Number of
> c
if (tuples > 0)
{
- if (tableinfo.relkind !=
RELKIND_PARTITIONED_TABLE)
- printfPQExpBuffer(&buf, _("Number of
child tables: %d (Use \\d+ to list them.)"), tuples);
-
On Mon, Sep 4, 2017 at 10:34 AM, Amit Langote
wrote:
> Hi Ashutosh,
>
> On 2017/09/04 13:51, Ashutosh Bapat wrote:
>> Hi,
>> Thomas's application to track patches told me that this patch needs
>> rebase. It also required some changes to the code. Here's the updated
>> version. I have squashed thos
Hi Ashutosh,
On 2017/09/04 13:51, Ashutosh Bapat wrote:
> Hi,
> Thomas's application to track patches told me that this patch needs
> rebase. It also required some changes to the code. Here's the updated
> version. I have squashed those two patches together.
Thanks for the rebased patch.
Would i
Hi,
Thomas's application to track patches told me that this patch needs
rebase. It also required some changes to the code. Here's the updated
version. I have squashed those two patches together.
On Tue, Mar 14, 2017 at 6:35 PM, Ashutosh Bapat
wrote:
> Added this to 2017/7 commitfest to keep a tra
Added this to 2017/7 commitfest to keep a track of it.
On Wed, Mar 8, 2017 at 3:39 PM, Amit Langote
wrote:
> On 2017/03/08 18:27, Ashutosh Bapat wrote:
>>>
>>> About the other statement you changed, I just realized that we should
>>> perhaps do one more thing. Show the Number of partitions, even
On 2017/03/08 18:27, Ashutosh Bapat wrote:
>>
>> About the other statement you changed, I just realized that we should
>> perhaps do one more thing. Show the Number of partitions, even if it's 0.
>> In case of inheritance, the parent table stands on its own when there are
>> no child tables, but
>
> About the other statement you changed, I just realized that we should
> perhaps do one more thing. Show the Number of partitions, even if it's 0.
> In case of inheritance, the parent table stands on its own when there are
> no child tables, but a partitioned table doesn't in the same sense.
Hi Ashutosh,
On 2017/03/06 18:19, Ashutosh Bapat wrote:
> On Mon, Mar 6, 2017 at 11:12 AM, Ashutosh Bapat wrote:
>> On Mon, Mar 6, 2017 at 11:05 AM, Simon Riggs wrote:
>>> "has partitions" is not part of the DDL, whereas "FOR VALUES FROM (0)
>>> TO (100)" is. So ISTM sensible to differentiate bet
On Mon, Mar 6, 2017 at 11:12 AM, Ashutosh Bapat
wrote:
> On Mon, Mar 6, 2017 at 11:05 AM, Simon Riggs wrote:
>> On 6 March 2017 at 05:29, Ashutosh Bapat
>> wrote:
>>
>>> Just to confirm, you want the output to look like this
> \d+ t1
> Table "public.t1
On 2017/03/06 14:25, Simon Riggs wrote:
> On 6 March 2017 at 04:00, Ashutosh Bapat wrote:
>> Thinking about how to display partition which are further partitioned,
>> there are two options. Assume a partitioned table t1 with partitions
>> t1p1, which is further partitioned and t1p2. One could displ
On Mon, Mar 6, 2017 at 11:05 AM, Simon Riggs wrote:
> On 6 March 2017 at 05:29, Ashutosh Bapat
> wrote:
>
>> Just to confirm, you want the output to look like this
\d+ t1
Table "public.t1"
Column | Type | Collation | Nullable | Default | Stor
On 6 March 2017 at 05:29, Ashutosh Bapat
wrote:
> Just to confirm, you want the output to look like this
>>> \d+ t1
>>> Table "public.t1"
>>> Column | Type | Collation | Nullable | Default | Storage | Stats
>>> target | Description
>>> +-+--
On Mon, Mar 6, 2017 at 10:55 AM, Simon Riggs wrote:
> On 6 March 2017 at 04:00, Ashutosh Bapat
> wrote:
>> On Mon, Mar 6, 2017 at 8:35 AM, Simon Riggs wrote:
>>> On 6 March 2017 at 00:51, Amit Langote
>>> wrote:
On 2017/03/05 16:20, Simon Riggs wrote:
> I notice also that
> \d+
On 6 March 2017 at 04:00, Ashutosh Bapat
wrote:
> On Mon, Mar 6, 2017 at 8:35 AM, Simon Riggs wrote:
>> On 6 March 2017 at 00:51, Amit Langote wrote:
>>> On 2017/03/05 16:20, Simon Riggs wrote:
I notice also that
\d+
does not show which partitions have subpartitions.
>>>
>>> Do
On Mon, Mar 6, 2017 at 8:35 AM, Simon Riggs wrote:
> On 6 March 2017 at 00:51, Amit Langote wrote:
>> On 2017/03/05 16:20, Simon Riggs wrote:
>>> I notice also that
>>> \d+
>>> does not show which partitions have subpartitions.
>>
>> Do you mean showing just whether a partition is itself parti
On 6 March 2017 at 00:51, Amit Langote wrote:
> On 2017/03/05 16:20, Simon Riggs wrote:
>> I notice also that
>> \d+
>> does not show which partitions have subpartitions.
>
> Do you mean showing just whether a partition is itself partitioned or
> showing its partitions and so on (because those
On 2017/03/05 16:20, Simon Riggs wrote:
> I notice also that
> \d+
> does not show which partitions have subpartitions.
Do you mean showing just whether a partition is itself partitioned or
showing its partitions and so on (because those partitions may themselves
be partitioned)? Maybe, we cou
On 5 March 2017 at 07:59, Ashutosh Bapat
wrote:
>>
>> I used a slight modification of the case mentioned on the docs. I
>> confirm this fails repeatably for me on current HEAD.
>>
>> CREATE TABLE cities (
>> city_id bigserial not null,
>> name text not null,
>> populati
>
> I used a slight modification of the case mentioned on the docs. I
> confirm this fails repeatably for me on current HEAD.
>
> CREATE TABLE cities (
> city_id bigserial not null,
> name text not null,
> population bigint
> ) PARTITION BY LIST (left(lower(name), 1));
On 27 February 2017 at 02:38, Amit Langote
wrote:
> On 2017/02/26 5:30, Simon Riggs wrote:
>> On 23 February 2017 at 16:33, Simon Riggs wrote:
>>
>>> I'll be happy to review
>>
>> Patch looks OK so far, but fails on a partition that has partitions,
>> probably because of the way we test relkind
>>
>> Isn't list_range_parted multilevel partitioned table. It gets dropped
>> in the testcases. So, I guess, we already have a testcase there.
>
> I thought Simon meant the test case where a partition that is itself
> partitioned is dropped. At least that's what I took from "... fails *on*
> part
On 2017/02/27 13:35, Ashutosh Bapat wrote:
> On Mon, Feb 27, 2017 at 8:08 AM, Amit Langote
> wrote:
>> On 2017/02/26 5:30, Simon Riggs wrote:
>>> On 23 February 2017 at 16:33, Simon Riggs wrote:
>>>
I'll be happy to review
>>>
>>> Patch looks OK so far, but fails on a partition that has par
On Mon, Feb 27, 2017 at 8:08 AM, Amit Langote
wrote:
> On 2017/02/26 5:30, Simon Riggs wrote:
>> On 23 February 2017 at 16:33, Simon Riggs wrote:
>>
>>> I'll be happy to review
>>
>> Patch looks OK so far, but fails on a partition that has partitions,
>> probably because of the way we test relki
On 2017/02/26 5:30, Simon Riggs wrote:
> On 23 February 2017 at 16:33, Simon Riggs wrote:
>
>> I'll be happy to review
>
> Patch looks OK so far, but fails on a partition that has partitions,
> probably because of the way we test relkind in the call to
> StoreCatalogInheritance1().
Thanks for
On 23 February 2017 at 16:33, Simon Riggs wrote:
> I'll be happy to review
Patch looks OK so far, but fails on a partition that has partitions,
probably because of the way we test relkind in the call to
StoreCatalogInheritance1().
Please add a test for that so we can check automatically.
Than
On 2017/02/24 1:33, Simon Riggs wrote:
> On 23 February 2017 at 06:40, Ashutosh Bapat
> wrote:
>
>> I think this is ready for committer.
>
> Thanks for writing and reviewing this. I'll be happy to review and
> commit. Please add to CF.
Thanks. I've added it to CF: https://commitfest.postgresql
On 23 February 2017 at 06:40, Ashutosh Bapat
wrote:
> I think this is ready for committer.
Thanks for writing and reviewing this. I'll be happy to review and
commit. Please add to CF.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Tr
I think this is ready for committer.
On Thu, Feb 23, 2017 at 12:02 PM, Amit Langote
wrote:
> On 2017/02/22 21:24, Ashutosh Bapat wrote:
>> On Wed, Feb 22, 2017 at 11:11 AM, Amit Langote wrote:
>>> + /*
>>> +* Unlike inheritance children, partition tables are expected to be
>>> drop
On 2017/02/22 21:24, Ashutosh Bapat wrote:
> On Wed, Feb 22, 2017 at 11:11 AM, Amit Langote wrote:
>> + /*
>> +* Unlike inheritance children, partition tables are expected to be
>> dropped
>> +* when the parent partitioned table gets dropped.
>> +*/
>>
>> Hmm. Partit
On Wed, Feb 22, 2017 at 11:11 AM, Amit Langote
wrote:
> On 2017/02/22 13:46, Ashutosh Bapat wrote:
>> Looks good to me. In the attached patch I have added a comment
>> explaining the reason to make partition tables "Auto" dependent upon
>> the corresponding partitioned tables.
>
> Good call.
>
> +
On 2017/02/22 13:46, Ashutosh Bapat wrote:
> Looks good to me. In the attached patch I have added a comment
> explaining the reason to make partition tables "Auto" dependent upon
> the corresponding partitioned tables.
Good call.
+ /*
+* Unlike inheritance children, partition tables
Looks good to me. In the attached patch I have added a comment
explaining the reason to make partition tables "Auto" dependent upon
the corresponding partitioned tables.
In the tests we are firing commands to drop partitioned table, but are
not checking whether those tables or the partitions are g
On 2017/02/22 10:49, Amit Langote wrote:
> On 2017/02/21 20:17, Ashutosh Bapat wrote:
>> Are you sure you have attached the right patch?
>
> Oops, really fixed this time.
Sorry again, 3rd time's a charm. I copy-paste the hunk below from the
patch file before I attach it to make sure:
- re
On 2017/02/21 20:17, Ashutosh Bapat wrote:
> On Tue, Feb 21, 2017 at 12:05 PM, Amit Langote wrote:
>> On 2017/02/20 21:49, Ashutosh Bapat wrote:
>>> Here are some comments
>>>
>>> For the sake of readability you may want reverse the if and else order.
>>> -recordDependencyOn(&childobject, &pare
On Tue, Feb 21, 2017 at 12:05 PM, Amit Langote
wrote:
> Hi Ashutosh,
>
> Thanks for taking a look at the patch.
>
> On 2017/02/20 21:49, Ashutosh Bapat wrote:
>> Thanks for working on all the follow on work for partitioning feature.
>>
>> May be you should add all those patches in the next commitf
On 2017/02/21 15:35, Amit Langote wrote:
>> drop table list_parted cascade;
>> -NOTICE: drop cascades to 3 other objects
>> -DETAIL: drop cascades to table part_ab_cd
>> probably we should remove cascade from there, unless you are testing CASCADE
>> functionality. Similarly for other blocks like
Hi Ashutosh,
Thanks for taking a look at the patch.
On 2017/02/20 21:49, Ashutosh Bapat wrote:
> Thanks for working on all the follow on work for partitioning feature.
>
> May be you should add all those patches in the next commitfest, so
> that we don't forget those.
I think adding these as on
Thanks for working on all the follow on work for partitioning feature.
May be you should add all those patches in the next commitfest, so
that we don't forget those.
On Mon, Feb 20, 2017 at 7:46 AM, Amit Langote
wrote:
> Re-posting the patch I posted in a nearby thread [0].
>
> On 2017/02/16 2:0
50 matches
Mail list logo
