Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

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 |

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

On Mon, Sep 4, 2017 at 3:48 PM, Alvaro Herrera wrote: > > if (tuples > 0) > { > - if (tableinfo.relkind != > RELKIND_PARTITIONED_TABLE) > -

Re: [HACKERS] dropping partitioned tables without CASCADE

if (tuples > 0) { - if (tableinfo.relkind != RELKIND_PARTITIONED_TABLE) - printfPQExpBuffer(, _("Number of child tables: %d (Use \\d+ to list them.)"), tuples); -

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

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.

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

> > 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.

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

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"

Re: [HACKERS] dropping partitioned tables without CASCADE

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 |

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

> > 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),

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

>> >> 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* >

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

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 >

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

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.

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

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: [HACKERS] dropping partitioned tables without CASCADE

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(, ,

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

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

Re: [HACKERS] dropping partitioned tables without CASCADE

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