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