Re: Declarative partitioning in pgAdmin4

From: Shirley Wang <swang(at)pivotal(dot)io>
To: Ashesh Vashi <ashesh(dot)vashi(at)enterprisedb(dot)com>
Cc: Robert Eckhardt <reckhardt(at)pivotal(dot)io>, Akshay Joshi <akshay(dot)joshi(at)enterprisedb(dot)com>, pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>, Dave Page <dpage(at)pgadmin(dot)org>
Subject: Re: Declarative partitioning in pgAdmin4
Date: 2017-06-14 22:20:51
Message-ID: CAPG3WN7w4LeN8unYdOP_E_1j6yixsJ88BFOEehyxzqVYuDyOFw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

On Wed, Jun 14, 2017 at 3:42 AM Ashesh Vashi <ashesh(dot)vashi(at)enterprisedb(dot)com>
wrote:

> Hi Shirley,
>
>
> Please see my reply inline..
> On Wed, Jun 14, 2017 at 5:29 AM, Shirley Wang <swang(at)pivotal(dot)io> wrote:
>
>> Some questions/comments/sketches:
>>
>> - The constraints tab as is implemented now enables constraints for the
>> parent table, correct? If so, and if someone wants to apply constraints to
>> partitions, as I understand it they would need to apply that to each child
>> partition. If that is true, then the tab structure along the top would need
>> to change to show constraints only after child partitions are created to
>> avoid confusion. OR perhaps at the menu level, have an option for creating
>> a partitioned table rather than table.
>>
> Couple of observation about the table constraints:
>
> - PostgreSQL allow to create CHECK constraint on both partition (parent)
> table, and its children partitions.
> - Rest of the constraints may not be applicable on the parent table.
>
> So - the question is: whether we should allow to create constraints for
> the child partitions from the parent node, or not.
>
> If yes - then:
> We will need a switch control (flag) in each of the constraints (in the
> subnode control) to distinguish whether the constraint will be applied on
> parent/child table.
>

> It think - we can also implement bulk triggers, constraints, indexes from
> the parent table, which can be applied to all the children partitions.
> We can give these functionality in the
>

I agree with you, potentially, as long as users are only seeing relevant
info on that screen. For example, if only CHECK constraints work, if a user
is creating a partitioned table they shouldn't be able to see non-working
functionality. And if a user is creating a regular table, they should not
see any additional UI elements that only relate to partitioning,

With what we have now, is there a way to do that gracefully? I feel like
it'll be kind of difficult to navigate, especially with constraints. What
are your thoughts on having 'Create -table' and 'Create-partitioned table'
as two separate options?

>
>> - The steps to create a table with partitions seems to have very clear
>> steps. I think it would benefit from a more 'wizard-like' step by step
>> flow.
>>
> Hmm.
> Are you saying - we should switch to use the Wizard for table creation?
> I think - that should be done in as a separate module.
>
> Any way - we will need to properties dialog for editing the properties of
> an existing partition table.
>

yes definitely. I don't think they need to be separate, the properties
dialog could be a part of 'wizard'. Also, what do you mean by done in a
separate module

In response to

Browse pgadmin-hackers by date

  From Date Subject
Next Message Harshal Dhumal 2017-06-14 22:22:49 Re: pgAdmin 4 commit: Use a more sensible name for Query Tool tabs. Fixes #
Previous Message Sarah McAlear 2017-06-14 19:46:30 Re: [patch] History Detail Pane