Re: [pgadmin-hackers] pgAdmin 4 commit: Add support for detachable tabs to the runtime.

2017-06-16 Thread Robert Eckhardt 
Nice! This is awesome. I didn't see it land.

-- Rob

On Fri, Jun 16, 2017 at 1:57 AM, Dave Page  wrote:

> Add support for detachable tabs to the runtime.
>
> This allows the Query Tool, Debugger and web browser tabs to be moved to
> different monitors as desired.
>
> Fixes #1344
>
> Branch
> --
> master
>
> Details
> ---
> https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=
> 0056a94115416c12690f58af3b77b9ce7c02da95
> Author: Neel Patel 
>
> Modified Files
> --
> runtime/BrowserWindow.cpp | 337 +---
> runtime/BrowserWindow.h   |  15 +-
> runtime/TabWindow.cpp | 542 ++
> +---
> runtime/TabWindow.h   | 151 -
> runtime/WebViewWindow.cpp |  82 +++
> runtime/WebViewWindow.h   |  17 +-
> runtime/back.png  | Bin 448 -> 290 bytes
> runtime/close.png | Bin 587 -> 346 bytes
> runtime/forward.png   | Bin 445 -> 270 bytes
> runtime/pgAdmin4.cpp  |  15 +-
> runtime/pgAdmin4.qrc  |   1 +
> runtime/qss/pgadmin4.qss  |   3 +
> 12 files changed, 937 insertions(+), 226 deletions(-)
>
>
> --
> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-hackers
>

Re: [pgadmin-hackers][patch] History Detail Pane

2017-06-14 Thread Robert Eckhardt 
Absolutely makes sense.

Matt, Sarah,

Do we understand the issues Dave is mentioning well enough to look into it
and tackle it?

-- Rob

On Wed, Jun 14, 2017 at 8:12 AM, Dave Page  wrote:

> Hi,
>
> Before I commit anything else for this patch, we need to fix the
> existing changes so they work in the desktop runtime (see the previous
> thread with the patches for the history pane changes). Have any of
> your team been able to look at that yet?
>
> On Wed, Jun 14, 2017 at 4:07 PM, Sarah McAlear 
> wrote:
> > Hi Hackers!
> >
> > This patch includes a new pane in the history tab that displays the full
> > formatted query and meta data about the query.
> >
> > Thanks!
> > Shruti & Sarah
> >
> >
> >
> >
> >
> >
> > --
> > Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
> > To make changes to your subscription:
> > http://www.postgresql.org/mailpref/pgadmin-hackers
> >
>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
> --
> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-hackers
>

Re: [pgadmin-hackers] Declarative partitioning in pgAdmin4

2017-06-13 Thread Robert Eckhardt 
Akshay,

Have you determined the minimum feature set you are shooting for before you
commit this? The reason I ask is that we were thinking that some level of
simple automation would probably be nice to make this super useful.

Basically if you consider a simple example of partitioning 90 days of data
by day the manual process of creating the names and to - from fields
becomes rather painful. If you couple that with potentially wanting to do
list subpartitioning if just multiplies the work.

If we could get something committed then we could more easily work to
define where simple automation makes sense and where it doesn't.

-- Rob

On Tue, Jun 13, 2017 at 6:59 AM, Akshay Joshi  wrote:

> Hi All
>
> For further implementation following task needs to be work upon:
>
>- How to parse and show partitions keys. For example user has created
>below partitioned table
>
> CREATE TABLE public.sales
> (
> country character varying COLLATE pg_catalog."default" NOT NULL,
> sales bigint,
> saledate date
> ) PARTITION BY RANGE (*country, date_part('year'::text, sale date)*)
>
> When user open the properties dialog I am not able to figure out how to
> parse keys(displayed in bold in above example) and show them in our control
> that we used. For the time being I have hide that control in 'Edit' mode
> (Refer Attach Partition.png)
>
>
>- *Support of sub partitioning*: To implement sub-partitioning,
>specify the PARTITION BY clause in the commands used to create individual
>partitions, for example:
>-
>
>CREATE TABLE measurement_y2006 PARTITION OF measurement
>FOR VALUES FROM ('2006-02-01') TO ('2006-03-01')
>PARTITION BY RANGE (peaktemp);
>
>
>To achieve above I have made some changes in GUI (Refer Sub
> Partition.png).
>*Complex and challenging part here is "measurement_y2006" is
> partition of "measurement" and parent table for other partitions too which
> user can create later. How we will going to show this in browser tree? *
>One option could be
>Tables
>  ->measurement(table)
>->Partitions
>  ->measurement_y2006(Partition of measurement and parent
> of p1)
>->Partitions
>  ->p1
>
>- *Attach Partitions*: To implement attach N partitions I have made
>some changes in GUI( Refer Attach Partition.png). Attach Partitions
>control will only be visible in "Edit" mode.
>
> I have only modified the UI changes, there are lots of work needs to be
> done to complete that.
> Please review the design. Suggestions/Comments are welcome.
>
>
> On Tue, Jun 6, 2017 at 4:30 PM, Robert Eckhardt 
> wrote:
>
>>
>>
>> On Tue, Jun 6, 2017 at 4:32 AM, Dave Page  wrote:
>>
>>>
>>> For roll up this pattern seems obvious, identify the n partitions you
>>>> need/want to combine and then run a job to combine them.
>>>>
>>>
>>> You're thinking Greenplum :-). There is no roll up in PostgreSQL, unless
>>> you're thinking we should create such a feature in pgAdmin.
>>>
>>> Of course, I have no objection to extending what we do in PG to add GP
>>> feature support, but let's start with PG.
>>>
>>
>> No not at all. That was a very specific and consistent pattern described
>> by users leveraging time based range partitions in Postgres. I'm not sure
>> if that same use case will be supported with partitioning as implemented in
>> Postgres 10 but it is a Postgres pattern.
>>
>> -- Rob
>>
>>
>>>
>>>
>>>>
>>>> For other patterns such as creating indexes and such it requires a bit
>>>> more thought. Generally users described wanting to treat all of the
>>>> children like a single table (just like Oracle), however, other users
>>>> described potentially modifying chunks of partitions differently depending
>>>> on some criterion. This means that users will need to identify the subset
>>>> they want to optimize and then ideally be able to act on them all at once.
>>>>
>>>
>>> Right.
>>>
>>>
>>>>
>>>> -- Rob
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> So... it sounds like we're on the right lines :-)
>>>>>
>>>>>
>>>>>>
>>>>>> For the former, this can be add

Re: [pgadmin-hackers] [pgAdmin4][Patch][RM_ 2477]: New Line text edit pop up renders off page when the size of the grid exceeds the size of the window

2017-06-12 Thread Robert Eckhardt 
Shirley and I are in SF this week so we will be even more async that usual.

-- Rob

On Mon, Jun 12, 2017 at 7:33 AM, Dave Page  wrote:

> Adding Shirley...
>
> Hi
>
> On Mon, Jun 12, 2017 at 2:27 PM, Surinder Kumar
>  wrote:
> > Hi
> >
> > The current font-family applied to slick-grid is
> 'Verdana,Arial,sans-serif'.
> > I tried changing it to "Helvetica Neue", Helvetica, Arial, sans-serif but
> > the font size and spacing between text is reduced. so to match style I
> used
> > "Verdana".
> >
> > Also, as per my knowledge, the Helvetica font will work only for
> Operating
> > Systems where this font actually exists in system, otherwise it will pick
> > Arial font.
> >
> > The right way to use 'Helvetica' is to download its 'ttf' and 'eot' files
> > and use in CSS so that it appears same on all machines:
> > https://stackoverflow.com/questions/13013616/css-
> helvetica-neue-not-working
> >
> > But it seems it is not available for free
> > https://www.myfonts.com/fonts/linotype/neue-helvetica/licensing.html
>
> Oh, that's not good. I assume we were relying on it being on a users
> machine already. I think we need to do one of two things:
>
> 1) Default to a font that we know should exist everywhere.
> 2) Have a fallback from Helvetica Neue to Arial or similar.
> 3) Choose something completely new and free, and ship it with the app.
>
> I prefer 1 if possible, then 2, finally 3.
>
> Shirley, any thoughts?
>
>
> > On Mon, Jun 12, 2017 at 6:16 PM, Dave Page  wrote:
> >>
> >> Hi
> >>
> >> Can you update this so that the CSS all follows the standards in the
> >> WIP styleguide please? I see that the current patch is using the wrong
> >> font for example.
> >>
> >> http://pgadmin4-styleguide.cfapps.io/
> >>
> >> Thanks!
> >>
> >> On Mon, Jun 12, 2017 at 11:57 AM, Surinder Kumar
> >>  wrote:
> >> > Hi
> >> >
> >> > Changes:
> >> >
> >> > 1) Calculate text editor position properly when the size of the grid
> >> > exceeds
> >> > the size of the window.
> >> >
> >> > 2) Assign NumberEditor to cell types('oid', 'xid', 'real').
> >> >
> >> > 3) Remove inline styles from rendered editors and move its styles to
> CSS
> >> > file.
> >> >
> >> > Please find attached patch and review.
> >> >
> >> > Thanks
> >> > Surinder
> >> >
> >> >
> >> > --
> >> > Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org
> )
> >> > To make changes to your subscription:
> >> > http://www.postgresql.org/mailpref/pgadmin-hackers
> >> >
> >>
> >>
> >>
> >> --
> >> Dave Page
> >> Blog: http://pgsnake.blogspot.com
> >> Twitter: @pgsnake
> >>
> >> EnterpriseDB UK: http://www.enterprisedb.com
> >> The Enterprise PostgreSQL Company
> >
> >
>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
> --
> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-hackers
>

Re: [pgadmin-hackers] [pgAdmin4][PATCH] Consolidating gray colors in the application

2017-06-07 Thread Robert Eckhardt 
Thank you.

-- Rob

On Wed, Jun 7, 2017 at 9:28 AM, Surinder Kumar <
surinder.ku...@enterprisedb.com> wrote:

> Sure I will send.
>
> On Wed, Jun 7, 2017 at 6:54 PM, Dave Page  wrote:
>
>> On Wed, Jun 7, 2017 at 2:22 PM, Surinder Kumar
>>  wrote:
>> > Hi
>> >
>> > With the latest pull, I found:
>> > The header color of Properties panel disappears and background color of
>> > footer area in Edit Properties panel is changed.
>>
>> Oh, I missed that :-(. Can you come up with a quick fix using the new
>> classes?
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>
>

Re: [pgadmin-hackers] Declarative partitioning in pgAdmin4

2017-06-06 Thread Robert Eckhardt 
On Tue, Jun 6, 2017 at 4:32 AM, Dave Page  wrote:

>
> For roll up this pattern seems obvious, identify the n partitions you
>> need/want to combine and then run a job to combine them.
>>
>
> You're thinking Greenplum :-). There is no roll up in PostgreSQL, unless
> you're thinking we should create such a feature in pgAdmin.
>
> Of course, I have no objection to extending what we do in PG to add GP
> feature support, but let's start with PG.
>

No not at all. That was a very specific and consistent pattern described by
users leveraging time based range partitions in Postgres. I'm not sure if
that same use case will be supported with partitioning as implemented in
Postgres 10 but it is a Postgres pattern.

-- Rob


>
>
>>
>> For other patterns such as creating indexes and such it requires a bit
>> more thought. Generally users described wanting to treat all of the
>> children like a single table (just like Oracle), however, other users
>> described potentially modifying chunks of partitions differently depending
>> on some criterion. This means that users will need to identify the subset
>> they want to optimize and then ideally be able to act on them all at once.
>>
>
> Right.
>
>
>>
>> -- Rob
>>
>>
>>
>>
>>
>>
>>>
>>> So... it sounds like we're on the right lines :-)
>>>
>>>
>>>>
>>>> For the former, this can be addressed by enabling users to modify one
>>>> or more child partitions at the same time. For the latter, that is a
>>>> workflow that might be addressed outside of the create table with partition
>>>> workflow we're working on currently.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Jun 5, 2017 at 5:21 AM Dave Page  wrote:
>>>>
>>>>> On Fri, Jun 2, 2017 at 9:01 AM, Akshay Joshi <
>>>>> akshay.jo...@enterprisedb.com> wrote:
>>>>>
>>>>>> Hi All
>>>>>>
>>>>>> Following are the further implementation updates to support
>>>>>> Declarative Partitioning:
>>>>>>
>>>>>>- Show all the existing partitions of the parent table in
>>>>>>Partitions tab (Refer Existing_Partitions.png)
>>>>>>- Ability to create N partitions and detach existing partitions.
>>>>>>Refer (Create_Detach_Partition.png), in this example I have
>>>>>>detach two existing partition and create two new partitions.
>>>>>>- Added "Detach Partition" menu to partitions node only and user
>>>>>>will be able to detach from there as well. Refer (Detach.png)
>>>>>>
>>>>>> That's looking good to me :-)
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, May 24, 2017 at 8:00 PM, Robert Eckhardt <
>>>>>> reckha...@pivotal.io> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, May 24, 2017 at 3:35 AM, Akshay Joshi <
>>>>>>> akshay.jo...@enterprisedb.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>Taking average of two columns is just an example/representation
>>>>>>>> of expression, there is no use case of that. As I am also in learning
>>>>>>>> phase. Below are some use case that I can think of:
>>>>>>>>
>>>>>>>>-
>>>>>>>>
>>>>>>>>Partitions based on first letter of their username
>>>>>>>>
>>>>>>>>CREATE TABLE users (
>>>>>>>>id serial not null,
>>>>>>>>username   text not null,
>>>>>>>>password   text,
>>>>>>>>created_on timestamptz not null,
>>>>>>>>last_logged_on timestamptz not null
>>>>>>>>)PARTITION BY RANGE ( lower( left( username, 1 ) ) );
>>>>>>>>CREATE TABLE users_0
>>>>>>>>partition of users (id, primary key (id), unique (username))
>>>>>>>>for values from ('a') to ('g');
>>>>>>>>CREATE TABLE users_1
>>>>>>>

Re: [pgadmin-hackers] [pgAdmin4][PATCH] Improvements to Query Results Grid User Experience

2017-06-05 Thread Robert Eckhardt 
On Mon, Jun 5, 2017 at 9:09 AM, Surinder Kumar <
surinder.ku...@enterprisedb.com> wrote:

> Hi Matthew,
>
> Couple of review comments:
> 1) Clicking on a new added row(after save) results in console error -
> screenshot attached.
>

We'll check this out as soon as we can.


> 2) If i drag to select rows inside the edit grid, columns headers are also
> highlighted which shouldn't i think as a user.
>

The idea behind this was that both column headers and row headers would
highlight so that the user could easily see what they had highlighted
inside the query results frame.

To be clear about the expected behavior.

   - If only full rows are selected then only row headers highlight
   - if only full columns are selected then only column headers highlight
   - if a rectangular subsection is selected then both row headers and
   column headers are highlighted

What were your expectations?

-- Rob


>
> New design of edit grid looks good :)
>
> Thanks
> Surinder
>
> On Fri, Jun 2, 2017 at 8:32 PM, Matthew Kleiman 
> wrote:
>
>> Hi Dave!
>>
>> It looks like everything has been addressed with this current patch,
>> aside from the feature test for for edit table tool. If we agree that
>> Surinder can send that patch on a separate thread, is this patch good to be
>> committed?
>>
>> Thanks,
>> Matt
>>
>> On Thu, Jun 1, 2017 at 11:17 AM, Robert Eckhardt 
>> wrote:
>>
>>> Awesome, thanks.
>>>
>>> -- Rob
>>>
>>> On Thu, Jun 1, 2017 at 11:13 AM, Surinder Kumar <
>>> surinder.ku...@enterprisedb.com> wrote:
>>>
>>>> Hi Robert,
>>>>
>>>> On Jun 1, 2017 8:22 PM, "Robert Eckhardt"  wrote:
>>>> >
>>>> > Surindar,
>>>> >
>>>> > Have you sent this patch and I'm missing it or is it still in flight
>>>> for you?
>>>> I have found the solution, will test that patch and hopefully by
>>>> tomorrow I will send.
>>>>
>>>> >
>>>> > -- Rob
>>>> >
>>>> > On Wed, May 31, 2017 at 1:02 AM, Surinder Kumar <
>>>> surinder.ku...@enterprisedb.com> wrote:
>>>> >>
>>>> >> Hi Joao
>>>> >>
>>>> >> On Wed, May 31, 2017 at 1:19 AM, Joao Pedro De Almeida Pereira <
>>>> jdealmeidapere...@pivotal.io> wrote:
>>>> >>>
>>>> >>> Hello
>>>> >>>
>>>> >>> We have rebased the patches against master again, which includes
>>>> Surinder's fix for RM2400. These patches should now apply against the HEAD
>>>> of master.
>>>> >>>>
>>>> >>>>
>>>> >>>> Given these issues, I think it would be sensible to add a feature
>>>> test
>>>> >>>> to copy/paste a couple of existing rows in a table, blank out the
>>>> pkey
>>>> >>>> values, save then refresh, and check everything looks right.
>>>> Thoughts?
>>>> >>>
>>>> >>> Currently, the feature test, CopySelectedQueryResultsFeatureTest,
>>>> only covers copy functionality in the query tool. It sounds like we could
>>>> use some additional coverage around the Edit Table tool, which could
>>>> include paste rows functionality. Can we get this patch merged and create a
>>>> RedMine issue that enumerates the additional functionality we want to cover
>>>> via feature test?
>>>> >>
>>>> >> ​FeatureTest for edit Table tool and copy/paste rows are already
>>>> written, but there is some flakiness when executing. I will be sending that
>>>> patch again with fix.​
>>>> >>>
>>>> >>>
>>>> >>> Thanks,
>>>> >>> Joao & Matt
>>>> >>>
>>>> >>>
>>>> >>> On Sat, May 27, 2017 at 2:19 PM, Dave Page 
>>>> wrote:
>>>> >>>>
>>>> >>>> On Sat, May 27, 2017 at 9:02 AM, Surinder Kumar
>>>> >>>>  wrote:
>>>> >>>> > Hi Dave,
>>>> >>>> > On Sat, May 27, 2017 at 3:07 AM, Dave Page 
>>>> wrote:
>>>> >>>> >>
>>>> >>>> >> Hi
>>>> >>>> >>
>>>> >>>> >> OK, so we'

Re: [pgadmin-hackers] Declarative partitioning in pgAdmin4

2017-06-05 Thread Robert Eckhardt 
I guess what I didn't say is YES. What Akshay and Ashesh are building is
going to absolutely be fundamental to any workflows being defined in these
interviews.

-- Rob

On Mon, Jun 5, 2017 at 12:17 PM, Robert Eckhardt 
wrote:

> On Mon, Jun 5, 2017 at 11:45 AM, Dave Page  wrote:
>
>>
>>
>> The former is what I was bleating about when I said we needed to expose
>> partitions to the user. The latter isn't relevant - declarative
>> partitioning in Postgres doesn't use inheritance.
>>
>
> The former is certainly the most interesting.  We do need to expose the
> partitions but only exposing them individually might be a bit overwhelming.
> What we found was that the number of partitions users have, (given existing
> means of leveraging partitions) vary from ~100 up to 10k. Basically what we
> were thinking about was how we can create a workflow/interface that allows
> users to modify one or more children at once. Furthermore, it would be nice
> if we could figure out an easy (easy-ish) way for users to identify the one
> or more partitions that need to be modified.
>
> For roll up this pattern seems obvious, identify the n partitions you
> need/want to combine and then run a job to combine them.
>
> For other patterns such as creating indexes and such it requires a bit
> more thought. Generally users described wanting to treat all of the
> children like a single table (just like Oracle), however, other users
> described potentially modifying chunks of partitions differently depending
> on some criterion. This means that users will need to identify the subset
> they want to optimize and then ideally be able to act on them all at once.
>
> -- Rob
>
>
>
>
>
>
>>
>> So... it sounds like we're on the right lines :-)
>>
>>
>>>
>>> For the former, this can be addressed by enabling users to modify one or
>>> more child partitions at the same time. For the latter, that is a workflow
>>> that might be addressed outside of the create table with partition workflow
>>> we're working on currently.
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Jun 5, 2017 at 5:21 AM Dave Page  wrote:
>>>
>>>> On Fri, Jun 2, 2017 at 9:01 AM, Akshay Joshi <
>>>> akshay.jo...@enterprisedb.com> wrote:
>>>>
>>>>> Hi All
>>>>>
>>>>> Following are the further implementation updates to support
>>>>> Declarative Partitioning:
>>>>>
>>>>>- Show all the existing partitions of the parent table in
>>>>>Partitions tab (Refer Existing_Partitions.png)
>>>>>- Ability to create N partitions and detach existing partitions.
>>>>>Refer (Create_Detach_Partition.png), in this example I have detach
>>>>>two existing partition and create two new partitions.
>>>>>- Added "Detach Partition" menu to partitions node only and user
>>>>>will be able to detach from there as well. Refer (Detach.png)
>>>>>
>>>>> That's looking good to me :-)
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> On Wed, May 24, 2017 at 8:00 PM, Robert Eckhardt >>>> > wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, May 24, 2017 at 3:35 AM, Akshay Joshi <
>>>>>> akshay.jo...@enterprisedb.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>Taking average of two columns is just an example/representation
>>>>>>> of expression, there is no use case of that. As I am also in learning
>>>>>>> phase. Below are some use case that I can think of:
>>>>>>>
>>>>>>>-
>>>>>>>
>>>>>>>Partitions based on first letter of their username
>>>>>>>
>>>>>>>CREATE TABLE users (
>>>>>>>id serial not null,
>>>>>>>username   text not null,
>>>>>>>password   text,
>>>>>>>created_on timestamptz not null,
>>>>>>>last_logged_on timestamptz not null
>>>>>>>)PARTITION BY RANGE ( lower( left( username, 1 ) ) );
>>>>>>>CREATE TABLE users_0
>>>>>>>partition of users (id, primary key (id), unique (username))
>>>>>>>for values fr

Re: [pgadmin-hackers] Declarative partitioning in pgAdmin4

2017-06-05 Thread Robert Eckhardt 
On Mon, Jun 5, 2017 at 11:45 AM, Dave Page  wrote:

>
>
> The former is what I was bleating about when I said we needed to expose
> partitions to the user. The latter isn't relevant - declarative
> partitioning in Postgres doesn't use inheritance.
>

The former is certainly the most interesting.  We do need to expose the
partitions but only exposing them individually might be a bit overwhelming.
What we found was that the number of partitions users have, (given existing
means of leveraging partitions) vary from ~100 up to 10k. Basically what we
were thinking about was how we can create a workflow/interface that allows
users to modify one or more children at once. Furthermore, it would be nice
if we could figure out an easy (easy-ish) way for users to identify the one
or more partitions that need to be modified.

For roll up this pattern seems obvious, identify the n partitions you
need/want to combine and then run a job to combine them.

For other patterns such as creating indexes and such it requires a bit more
thought. Generally users described wanting to treat all of the children
like a single table (just like Oracle), however, other users described
potentially modifying chunks of partitions differently depending on some
criterion. This means that users will need to identify the subset they want
to optimize and then ideally be able to act on them all at once.

-- Rob






>
> So... it sounds like we're on the right lines :-)
>
>
>>
>> For the former, this can be addressed by enabling users to modify one or
>> more child partitions at the same time. For the latter, that is a workflow
>> that might be addressed outside of the create table with partition workflow
>> we're working on currently.
>>
>>
>>
>>
>>
>> On Mon, Jun 5, 2017 at 5:21 AM Dave Page  wrote:
>>
>>> On Fri, Jun 2, 2017 at 9:01 AM, Akshay Joshi <
>>> akshay.jo...@enterprisedb.com> wrote:
>>>
>>>> Hi All
>>>>
>>>> Following are the further implementation updates to support Declarative
>>>> Partitioning:
>>>>
>>>>- Show all the existing partitions of the parent table in
>>>>Partitions tab (Refer Existing_Partitions.png)
>>>>- Ability to create N partitions and detach existing partitions.
>>>>Refer (Create_Detach_Partition.png), in this example I have detach
>>>>two existing partition and create two new partitions.
>>>>- Added "Detach Partition" menu to partitions node only and user
>>>>will be able to detach from there as well. Refer (Detach.png)
>>>>
>>>> That's looking good to me :-)
>>>
>>>
>>>
>>>>
>>>>
>>>> On Wed, May 24, 2017 at 8:00 PM, Robert Eckhardt 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, May 24, 2017 at 3:35 AM, Akshay Joshi <
>>>>> akshay.jo...@enterprisedb.com> wrote:
>>>>>
>>>>>>
>>>>>>Taking average of two columns is just an example/representation of
>>>>>> expression, there is no use case of that. As I am also in learning phase.
>>>>>> Below are some use case that I can think of:
>>>>>>
>>>>>>-
>>>>>>
>>>>>>Partitions based on first letter of their username
>>>>>>
>>>>>>CREATE TABLE users (
>>>>>>id serial not null,
>>>>>>username   text not null,
>>>>>>password   text,
>>>>>>created_on timestamptz not null,
>>>>>>last_logged_on timestamptz not null
>>>>>>)PARTITION BY RANGE ( lower( left( username, 1 ) ) );
>>>>>>CREATE TABLE users_0
>>>>>>partition of users (id, primary key (id), unique (username))
>>>>>>for values from ('a') to ('g');
>>>>>>CREATE TABLE users_1
>>>>>>partition of users (id, primary key (id), unique (username))
>>>>>>for values from ('g') to (unbounded);
>>>>>>
>>>>>>-  Partition based on country's sale for each month of an year.
>>>>>>
>>>>>> CREATE TABLE public.sales
>>>>>>
>>>>>> (
>>>>>>
>>>>>> country text NOT NULL,
>>>>>>
>>>>>> sales b

Re: [pgadmin-hackers] [pgAdmin4][PATCH] Improvements to Query Results Grid User Experience

2017-06-01 Thread Robert Eckhardt 
Awesome, thanks.

-- Rob

On Thu, Jun 1, 2017 at 11:13 AM, Surinder Kumar <
surinder.ku...@enterprisedb.com> wrote:

> Hi Robert,
>
> On Jun 1, 2017 8:22 PM, "Robert Eckhardt"  wrote:
> >
> > Surindar,
> >
> > Have you sent this patch and I'm missing it or is it still in flight for
> you?
> I have found the solution, will test that patch and hopefully by tomorrow
> I will send.
>
> >
> > -- Rob
> >
> > On Wed, May 31, 2017 at 1:02 AM, Surinder Kumar <
> surinder.ku...@enterprisedb.com> wrote:
> >>
> >> Hi Joao
> >>
> >> On Wed, May 31, 2017 at 1:19 AM, Joao Pedro De Almeida Pereira <
> jdealmeidapere...@pivotal.io> wrote:
> >>>
> >>> Hello
> >>>
> >>> We have rebased the patches against master again, which includes
> Surinder's fix for RM2400. These patches should now apply against the HEAD
> of master.
> >>>>
> >>>>
> >>>> Given these issues, I think it would be sensible to add a feature test
> >>>> to copy/paste a couple of existing rows in a table, blank out the pkey
> >>>> values, save then refresh, and check everything looks right. Thoughts?
> >>>
> >>> Currently, the feature test, CopySelectedQueryResultsFeatureTest,
> only covers copy functionality in the query tool. It sounds like we could
> use some additional coverage around the Edit Table tool, which could
> include paste rows functionality. Can we get this patch merged and create a
> RedMine issue that enumerates the additional functionality we want to cover
> via feature test?
> >>
> >> ​FeatureTest for edit Table tool and copy/paste rows are already
> written, but there is some flakiness when executing. I will be sending that
> patch again with fix.​
> >>>
> >>>
> >>> Thanks,
> >>> Joao & Matt
> >>>
> >>>
> >>> On Sat, May 27, 2017 at 2:19 PM, Dave Page  wrote:
> >>>>
> >>>> On Sat, May 27, 2017 at 9:02 AM, Surinder Kumar
> >>>>  wrote:
> >>>> > Hi Dave,
> >>>> > On Sat, May 27, 2017 at 3:07 AM, Dave Page 
> wrote:
> >>>> >>
> >>>> >> Hi
> >>>> >>
> >>>> >> OK, so we're getting somewhere now :-). Here's what I found:
> >>>> >>
> >>>> >> - The grid looks and feels great now. Selection works nicely, and
> >>>> >> copying rows seems to work well.
> >>>> >>
> >>>> >> - Patch 5 doesn't apply - but only to slick.grid.js. I manually
> fixed
> >>>> >> it for testing, but the patch really doesn't look like it was
> created
> >>>> >> from the version of the file from GIT HEAD with patches 1 - 4
> applied.
> >>>> >>
> >>>> >> - There is a problem. I noticed that a) when copy/pasting rows, if
> I
> >>>> >> blank out a key column with a default it gets set to [null]
> instead of
> >>>> >> [default] and b) inserting rows seems to get the values of the new
> >>>> >> row(s) from the wrong place, resulting in duplicate key violations.
> >>>> >
> >>>> > This belongs to RM2400 - handle [default] and [null] while
> copy/pasting
> >>>> > rows. An updated patch and Feature tests are already sent.
> >>>> > You can review and commit if looks good.
> >>>>
> >>>> That part, yes - but not mixing up the values.
> >>>>
> >>>>
> >>>> >> Now, both of these issues sound very much like ones Surinder fixed
> >>>> >> recently following other improvements to the grid to more properly
> >>>> >> handle nulls and default values. I *think* these fixes were in
> commit:
> >>>> >> d7d4bf475bc5b131d9a76376ebfc87e004d92333. Perhaps there's been a
> >>>> >> merging error in your development branch at some point?
> >>>> >>
> >>>> >> Given these issues, I think it would be sensible to add a feature
> test
> >>>> >> to copy/paste a couple of existing rows in a table, blank out the
> pkey
> >>>> >> values, save then refresh, and check everything looks right.
> Thoughts?
> >>>> >>
> >>>> >> I'm looking forward to seeing this fully baked :-

Re: [pgadmin-hackers] [pgAdmin4][PATCH] Improvements to Query Results Grid User Experience

2017-06-01 Thread Robert Eckhardt 
Surindar,

Have you sent this patch and I'm missing it or is it still in flight for
you?

-- Rob

On Wed, May 31, 2017 at 1:02 AM, Surinder Kumar <
surinder.ku...@enterprisedb.com> wrote:

> Hi Joao
>
> On Wed, May 31, 2017 at 1:19 AM, Joao Pedro De Almeida Pereira <
> jdealmeidapere...@pivotal.io> wrote:
>
>> Hello
>>
>> We have rebased the patches against master again, which includes
>> Surinder's fix for RM2400 .
>> These patches should now apply against the HEAD of master.
>>
>>>
>>> Given these issues, I think it would be sensible to add a feature test
>>> to copy/paste a couple of existing rows in a table, blank out the pkey
>>> values, save then refresh, and check everything looks right. Thoughts?
>>
>> Currently, the feature test, CopySelectedQueryResultsFeatureTest, only
>> covers copy functionality in the query tool. It sounds like we could use
>> some additional coverage around the Edit Table tool, which could include
>> paste rows functionality. Can we get this patch merged and create a RedMine
>> issue that enumerates the additional functionality we want to cover via
>> feature test?
>>
> ​FeatureTest for edit Table tool and copy/paste rows are already written,
> but there is some flakiness when executing. I will be sending that patch
> again with fix.​
>
>>
>> Thanks,
>> Joao & Matt
>>
>>
>> On Sat, May 27, 2017 at 2:19 PM, Dave Page  wrote:
>>
>>> On Sat, May 27, 2017 at 9:02 AM, Surinder Kumar
>>>  wrote:
>>> > Hi Dave,
>>> > On Sat, May 27, 2017 at 3:07 AM, Dave Page  wrote:
>>> >>
>>> >> Hi
>>> >>
>>> >> OK, so we're getting somewhere now :-). Here's what I found:
>>> >>
>>> >> - The grid looks and feels great now. Selection works nicely, and
>>> >> copying rows seems to work well.
>>> >>
>>> >> - Patch 5 doesn't apply - but only to slick.grid.js. I manually fixed
>>> >> it for testing, but the patch really doesn't look like it was created
>>> >> from the version of the file from GIT HEAD with patches 1 - 4 applied.
>>> >>
>>> >> - There is a problem. I noticed that a) when copy/pasting rows, if I
>>> >> blank out a key column with a default it gets set to [null] instead of
>>> >> [default] and b) inserting rows seems to get the values of the new
>>> >> row(s) from the wrong place, resulting in duplicate key violations.
>>> >
>>> > This belongs to RM2400 - handle [default] and [null] while copy/pasting
>>> > rows. An updated patch and Feature tests are already sent.
>>> > You can review and commit if looks good.
>>>
>>> That part, yes - but not mixing up the values.
>>>
>>>
>>> >> Now, both of these issues sound very much like ones Surinder fixed
>>> >> recently following other improvements to the grid to more properly
>>> >> handle nulls and default values. I *think* these fixes were in commit:
>>> >> d7d4bf475bc5b131d9a76376ebfc87e004d92333. Perhaps there's been a
>>> >> merging error in your development branch at some point?
>>> >>
>>> >> Given these issues, I think it would be sensible to add a feature test
>>> >> to copy/paste a couple of existing rows in a table, blank out the pkey
>>> >> values, save then refresh, and check everything looks right. Thoughts?
>>> >>
>>> >> I'm looking forward to seeing this fully baked :-)
>>> >>
>>> >> Thanks!
>>> >>
>>> >> On Fri, May 26, 2017 at 11:23 AM, Joao Pedro De Almeida Pereira
>>> >>  wrote:
>>> >> > Hello Dave,
>>> >> >
>>> >> > We created the previous patches using the command recommended in the
>>> >> > pgAdmin
>>> >> > website, but apparently the diff doesn't work correctly when you
>>> have
>>> >> > binary
>>> >> > files in the commit, like images.
>>> >> >
>>> >> > We regenerated the patches using the command with the addition of
>>> >> > --binary
>>> >> >
>>> >> > git diff e0d5cf6b ac65f43b --binary > 6-adapt-slickgrid-to-pgadmin.p
>>> atch
>>> >> >
>>> >> > After that, we applied them in master and this was the output:
>>> >> >
>>> >> > ± jp+si |master → origin {9} ✓| → git apply
>>> 1-upgrade-slickgrid.patch
>>> >> > 1-upgrade-slickgrid.patch:120: trailing whitespace.
>>> >> >
>>> >> > 1-upgrade-slickgrid.patch:129: trailing whitespace.
>>> >> >
>>> >> > 1-upgrade-slickgrid.patch:138: trailing whitespace.
>>> >> >
>>> >> > 1-upgrade-slickgrid.patch:147: trailing whitespace.
>>> >> >
>>> >> > 1-upgrade-slickgrid.patch:156: trailing whitespace.
>>> >> >
>>> >> > warning: squelched 3856 whitespace errors
>>> >> > warning: 3861 lines add whitespace errors.
>>> >> >
>>> >> >   maujer in ~/workspace/pgadmin4
>>> >> > ± jp+si |master → origin {9} U:17 ?:7 ✗| → git apply
>>> >> > 2-select-cells-improvements.patch
>>> >> >
>>> >> >   maujer in ~/workspace/pgadmin4
>>> >> > ± jp+si |master → origin {9} U:35 ?:12 ✗| → git apply
>>> >> > 3-drag-and-select.patch
>>> >> >
>>> >> >   maujer in ~/workspace/pgadmin4
>>> >> > ± jp+si |master → origin {9} U:41 ?:13 ✗| → git apply
>>> >> > 4-remove-checkboxes.patch
>>> >> >
>>> >> >   maujer in ~/workspace/pgadmin4
>>> >> > ± jp+si |master → origin {9} U:41

Re: [pgadmin-hackers] Autoformatting

2017-05-28 Thread Robert Eckhardt 
On Tue, May 9, 2017 at 4:26 AM, Dave Page  wrote:

>
> Anyhoo, The standard we try to use in pgAdmin at the moment is slightly
> different from the example you've given. To add it into the mix...
>
> /* Keywords Upper, 4 space indent, commas after, AND/OR after,
>  * no spaces after ( or before ), or around ::
>  */
> SELECT DISTINCT
> dep.deptype,
> dep.classid,
> coalesce(coc.relname, clrw.relname) AS ownertable
> FROM
> pg_depend dep
> LEFT JOIN pg_class cl ON dep.objid = cl.oid
> LEFT JOIN pg_attribute att ON dep.objid = att.attrelid AND
> dep.objsubid = att.attnum
> WHERE
> dep.objid = 16385::oid AND
> classid IN (
> SELECT
> oid
> FROM
> pg_class
> WHERE
> relname IN ('pg_class', 'pg_constraint')
> )
> ORDER BY
> classid,
> cl.relkind;
>
> There are some subtleties that are open to personal taste there;
>
> - Formatting of the sub-select - e.g. should the SELECT directly follow
> the (, and should the rest be indented accordingly?
>
> - Formatting of multiple quals in the joins; e.g. should the qual
> following the AND be on the next line, and if so, should it be indented one
> level, or to align with the qual above? Should the first qual be on the
> next line?
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

Sorry I let this linger. Let's go with the style you currently have. With
respect to your additional comments.

- Sub-Select should be a new line and indented as in your example.
- For multiple quals in the joins; the qual following the AND should be on
the next line, and should it be indented one level

-- Rob

Re: [pgadmin-hackers] Declarative partitioning in pgAdmin4

2017-05-24 Thread Robert Eckhardt 
On Wed, May 24, 2017 at 3:35 AM, Akshay Joshi  wrote:

>
>Taking average of two columns is just an example/representation of
> expression, there is no use case of that. As I am also in learning phase.
> Below are some use case that I can think of:
>
>-
>
>Partitions based on first letter of their username
>
>CREATE TABLE users (
>id serial not null,
>username   text not null,
>password   text,
>created_on timestamptz not null,
>last_logged_on timestamptz not null
>)PARTITION BY RANGE ( lower( left( username, 1 ) ) );
>CREATE TABLE users_0
>partition of users (id, primary key (id), unique (username))
>for values from ('a') to ('g');
>CREATE TABLE users_1
>partition of users (id, primary key (id), unique (username))
>for values from ('g') to (unbounded);
>
>-  Partition based on country's sale for each month of an year.
>
> CREATE TABLE public.sales
>
> (
>
> country text NOT NULL,
>
> sales bigint NOT NULL,
>
> saledate date
>
> ) PARTITION BY RANGE (country, (extract (YEAR FROM saledate)),
> (extract(MONTH FROM saledate)))
>
>
> CREATE TABLE public.sale_usa_2017_jan PARTITION OF sales
>
> FOR VALUES FROM ('usa', 2017, 01) TO ('usa', 2017, 02);
>
> CREATE TABLE public.sale_india_2017_jan PARTITION OF sales
>
> FOR VALUES FROM ('india', 2017, 01) TO ('india', 2017, 02);
>
> CREATE TABLE public.sale_uk_2017_jan PARTITION OF sales
>
> FOR VALUES FROM ('uk', 2017, 01) TO ('uk', 2017, 02);
>
>
> INSERT INTO sales VALUES ('india', 1, '2017-1-15');
>
> INSERT INTO sales VALUES ('uk', 2, '2017-1-08');
>
> INSERT INTO sales VALUES ('usa', 3, '2017-1-10');
>
>Apart from above there may be N number of use cases that depends on
> specific requirement of user.
>

Thank you for the example, you are absolutely correct and we were confused.

Given our new found understanding do you mind if we iterate a bit on the
UI/UX?  What we were suggesting with the daily/monthly/yearly drop down was
a specific example of an expression. Given that fact that doesn't seem to
be required in an MVP, however, I do think a more interactive experience
between the definition of the child partitions and the creation of the
partitions would be optimal.

I'm not sure where you are with respect to implementing the UI but I'd love
to float some ideas and mock ups past you.

-- Rob

Re: [pgadmin-hackers] Declarative partitioning in pgAdmin4

2017-05-23 Thread Robert Eckhardt 
On Tue, May 23, 2017 at 10:09 AM, Shirley Wang  wrote:

>
> It's possible to design for the range and list partitions and know we can
> achieve success because we understand how users would go through this
> workflow. Not sure about expressions.
>

Maybe to pile on this a bit.

When Shirley and I were discussing the workflows it was obvious when we
were looking at 'normal' range or list partition use cases. Generally the
only open question we had about the workflow was whether or not users would
be building tables net new or whether they were more likely to have a table
that was growing too large and therefore needed to create a new partitioned
table.

We couldn't think of a reason why a user would want to take the average of
two columns and partition by this derived value. It added to the question
of why/how a user would consider this as an idea a priori or whether this
would be an insight given analysis of existing data.

I assume this was supported for a specific use case. if you could share
that it would be awesome. I guess the long and short of it is, we are
having a difficult time imagining the workflow for this feature.

-- Rob

Re: [pgadmin-hackers] [patch] upgrade slickgrid

2017-05-18 Thread Robert Eckhardt 
On Thu, May 18, 2017 at 4:42 AM, Dave Page  wrote:

>
>
> Feel like putting that in your backlog? :-)
>

Interesting you say that. It is either going to be trivial to do or we
won't have the context on which vendored libraries have been changed. We
have a task to try and see if it is trivial. If it is we will submit a
patch shortly. If it isn't trivial we will probably start a conversation on
the mailing list with a list of tests that failed because of vendored
libraries.

-- Rob

Re: [pgadmin-hackers][patch] Dependents and Dependencies in GreenPlum

2017-05-04 Thread Robert Eckhardt 
All,

This change in the xss testing is preventing our CI from going green and is
also preventing the Dependents and Dependencies tabs in Greenplum from
being useful.

Can we either merge this or provide feedback as to what needs to change so
that it can be merged.

Thank you
Rob

On Tue, May 2, 2017 at 5:17 PM, Sarah McAlear  wrote:

> Hi Hackers & Ashesh!
>
> Is there anything else we can do for this?
>
> Thanks!
> Matt & Sarah
>
> On Thu, Apr 27, 2017 at 10:37 AM, Joao Pedro De Almeida Pereira <
> jdealmeidapere...@pivotal.io> wrote:
>
>> Thanks for reviewing, Ashesh.
>>
>> We have updated the patch. The headers are all consistent and we removed
>> the __init__.py files in directories containing only .sql.
>>
>> Thanks!
>> Joao & Matt
>>
>> On Wed, Apr 26, 2017 at 11:22 AM, Joao Pedro De Almeida Pereira <
>> jdealmeidapere...@pivotal.io> wrote:
>>
>>> Hello Ashesh,
>>>
>>> Thanks for reviewing the patch.
>>>
>>> We added the __init__.py files into templates to convert them into
>>> packages so that the tests inside of them can be found by the test runner.
>>>
>>> Thanks!
>>> Joao & Sarah
>>>
>>> On Wed, Apr 26, 2017 at 1:26 AM, Ashesh Vashi <
>>> ashesh.va...@enterprisedb.com> wrote:
>>>
 On Mon, Apr 24, 2017 at 4:43 PM, Dave Page  wrote:

> Ashesh, can you review/commit this please?
>
> On Fri, Apr 21, 2017 at 8:42 PM, Joao Pedro De Almeida Pereira <
> jdealmeidapere...@pivotal.io> wrote:
>
>> Hi Hackers,
>>
>> We found out that when you are connected to a GreenPlum database and
>> try to get Dependents and Dependencies of an object the application was
>> returning a SQL error.
>>
>> This patch splits the SQL query used to retrieve the Dependents,
>> Dependencies, and Roles SQL file into multiple versioned files.
>> Add Unit Tests for each file.
>> Also added __init__.py files to other test directories to run the
>> tests in them.
>>
> Hi Joao & Sarah,

 Why do we need to add __init__.py in the template directory?
 I didn't understand the purpose of the adding __init__.py files in the
 template directories.

 NOTE: The headers in those files are not consistent with the other
 project files.

 --

 Thanks & Regards,

 Ashesh Vashi
 EnterpriseDB INDIA: Enterprise PostgreSQL Company
 


 *http://www.linkedin.com/in/asheshvashi*
 

> Add ORDER BY into Copy Selection Feature test to ensure the results
>> are retrieved always in the same order
>> Renamed the Scenario of the xss_checks_pgadmin_debugger_test and
>> skip it for versions less than 9.1
>>
>> Thanks
>>
>> Joao & Sarah
>>
>>
>> --
>> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org
>> )
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgadmin-hackers
>>
>>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>


>>>
>>
>>
>> --
>> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgadmin-hackers
>>
>>
>

Re: [pgadmin-hackers] Declarative partitioning in pgAdmin4

2017-04-27 Thread Robert Eckhardt 
>
> The issues we consistently face:
>>
>>- The huge (often thousands sometimes tens of thousands) number of
>>partitions makes rendering all of the partitions painfully slow and
>>frequently not useful.
>>
>> Perhaps, though I doubt that number would be common in Postgres. The
> problem though, is that there are both stats and sub-objects (indexes and
> triggers for example) that are part of the child partitions, not the parent
> - and they may differ from partition to partition.
>

Certainly there differences in Postgres and Greenplum and this might very
well be one of those places.


> I don't see that we have any choice but to display them so users can work
> with them.
>

We don't want to hide them, I do think we want to make accessing them a
useful experience. If we rephrase this statement as "How might we display
partitioned tables so that users are able to work with and modify the
pieces they need?", this opens us up to different opportunities in how we
display them.

Even with a simple case of 90 days of data partitioned by day, a drop down
showing 90 tables that are all mostly the same is a little overwhelming.


>
>>- When end users are interested in looking at their partitions they
>>frequently don't want all of them displayed mindlessly
>>   - They are looking at a subset of partitions
>>   - Partitions are typically grouped around their inheritance
>>   properties.
>>
>> How might you propose grouping them (based on the way they work in
> Postgres)?
>

Honestly I'm not sure. We didn't really start thinking about this until the
other day so we are starting to look into the pains that Greenplum
customers have. Sharing that pain we discover back to the pgAdmin community
and seeing if it makes sense from a Postgres perspective.  After that I
need to dive into the Postgres implementation.

-- Rob

Re: [pgadmin-hackers] Declarative partitioning in pgAdmin4

2017-04-27 Thread Robert Eckhardt 
On Thu, Apr 27, 2017 at 7:01 AM, Akshay Joshi  wrote:

> Hi Dave
>
> As per discussion I have changed the logic of showing partitioned table in
> browser tree. Attached is the screenshot.
> Let me know your thoughts.
>

Greenplum has had declarative partitioning for quite some time, I haven't
spent much time diving into the Postgres implementation specifically,
however, we have had some pain and I would suggest a little bit of thought
behind this.

The issues we consistently face:

   - The huge (often thousands sometimes tens of thousands) number of
   partitions makes rendering all of the partitions painfully slow and
   frequently not useful.
   - When end users are interested in looking at their partitions they
   frequently don't want all of them displayed mindlessly
  - They are looking at a subset of partitions
  - Partitions are typically grouped around their inheritance
  properties.

-- Rob

Re: [pgadmin-hackers] [Design Update] Visual design of query editor and results table

2017-04-13 Thread Robert Eckhardt 
>
> Is that a new shade of gray? How many do we have now? It looks to me like
>>> it's starting to get messy, with too many different variations of gray plus
>>> the light blues used for the codemirror gutter and alternate rows in the
>>> grid.
>>>
>>
>> Yes, it is a darker shade of gray. Are you concerned with the number of
>> variations on gray, or that the grays are not used appropriately?
>>
>
> Both really.
>

The shade of gray, I think, doesn't really matter that much and remaining
consistent within the app is fine as long as there is sufficient contrast.

The use of gray is intentional. The idea being that the eye should be drawn
only to the area the user is actively working on.  In the picture the area
of focus is the query text editor and the blue bar above it actually draws
the eye there. After the user decides they need to inspect the results
adding blue there makes those results pop.

Let me state what I think your concerns are:

   1. The application is becoming too monochromatic and washed out
   2. the application is becoming too 'flat'

I think we agree that both of these things could be problematic, my guess
is where we don't agree is on the line.

Here are the assumptions we are designing to:

   - users are going to be on the application for multiple hours per day
   - a softer aesthetic makes it easier on the eyes for long term use.
   - color is important to make the product appealing
   - use of color should be intentional and done to change the users focus.

To my knowledge we haven't don't anything to make the application more or
less flat.


-- Rob

Re: [pgadmin-hackers] [Design Update] Visual design of query editor and results table

2017-04-06 Thread Robert Eckhardt 
>
> > 3. right-justified numbers come from precedents like excel or other
> > spreadsheet type tools and muddles the distinction between editable and
> > un-editable tables (at least data output in from query results is
> > un-editable, I know right clicking on a table in the browser to "view ...
> > data/rows" outputs an editable table)
>
> When we first released pgAdmin 4 we forgot to right-justify numbers.
> Users complained. Lots. They need to stay right justified.
>

Right justifying makes it substantially easier to understand magnitude and
makes it easier to get decimal alignment.

-- Rob


>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
> --
> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-hackers
>

[pgadmin-hackers] Results screen/Data output work

2017-02-16 Thread Robert Eckhardt 
All,

I was looking at the mailing list this morning and realized that we had
been remiss in discussing what we (Pivotal) are working on.

The primary chunk of work we are doing it to get The data output window to
behave similarly to how it behaves in pgAdmin3. Specifically we want users
to be able to drag highlight copy and paste, or select a cell and use key
board shortcuts to expand or shrink what is selected.

This work should be coming in as a few patches or patch sets.

   1. enable the ability to select columns in the query output
   2. enable drag and select in the query output
   3. Output selection modified by Shift+direction keyboard shortcuts
   - This increases or decreases the area selected by one unit
   4. Output selection modified by cmd-Shift+direction keyboard shortcuts
   - This increases or decreases the area selected to the end of the array

When we get to the point of having a technical approach we will update the
mailing list to discuss.

-- Rob

Re: [pgadmin-hackers] User Research Findings into PgAdmin

2017-01-25 Thread Robert Eckhardt 
>
> My main concern is making the right decisions on what to change, and
> focussing efforts in the areas where we gain most benefit. Of course,
> the resources to do the work are also critical - the current team
> already have a good years worth of work in various additional features
> and improvements.
>

Absolutely our concern as well which is why we don't want to work in a
vacuum.

-- Rob


>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

Re: [pgadmin-hackers] User Research Findings into PgAdmin

2017-01-25 Thread Robert Eckhardt 
One of the surprises for me when looking at the interview notes was the
number of features that people asked for that already existed. IMO one of
the wins for design would be making these more easily discovered. As I see
it a lot of the design is going to be fairly nuanced and having the
conversation to include the community in the process of discovery and
validation would be awesome if there is interest.

-- Rob

On Wed, Jan 25, 2017 at 9:38 AM, Raffi Holzer  wrote:

> Hi Dave,
>  We can definitely send a summary via email. Just to clarify those points
> you brought up. Syntax highlighting definitely does exist and is totally
> discoverable but people still seemed to miss it. Our best guess as to why
> so many users miss it is because of the relatively small contrast in colors
> (Navy vs black). Regarding autocomplete, despite it being documented,
> almost none of the long time customers we spoke with knew it existed which
> suggests they're not reading the documentation very closely or at all.
>
> Regarding the comments you mentioned, the one regarding column names was
> talking about preserving the column name when moving data to Excel. And
> I'll admit, the other comment is pretty unclear out of context. We probably
> should not have included it as is.
>
> A summary of the findings will be forthcoming.
>
> On Wed, Jan 25, 2017 at 4:25 AM, Dave Page  wrote:
>
>> Hi
>>
>> On Tue, Jan 24, 2017 at 9:42 PM, Raffi Holzer  wrote:
>> > Hi,
>> >  As part of a project to enable pgAdmin4 to work with Greenplum
>> databases,
>> > we conducted user research into pgAdmin. We wanted to share those
>> insights
>> > and potentially develop against them but first wanted to get feedback
>> from
>> > the pgAdmin group. To that end we created the video below that
>> summarizes
>> > our findings. Let us know what you think.
>> >
>> > https://youtu.be/BylcblYw8sU
>>
>> That's very helpful, thank you. Can you please summarise your findings
>> in an email to the list so we can work with it within our normal
>> process?
>>
>> I will note that whilst I agree some of the points raised need further
>> work in pgAdmin 4, some of them make little sense - most notably
>> Syntax Highlighting which we've had for ~17 years, and works
>> automatically, thus not requiring any kind of user discovery beyond
>> typing some SQL into the query tool. Auto-complete is another example
>> of a feature we've had for years, that is documented. I agree though
>> that there is scope for better discovery mechanisms there.
>>
>> Some of the other comments highlighted made little to no sense to me,
>> for example the comment on column names @ ~3:03 and the comment on the
>> bottom left @ ~3:22 (this is a great example of why email is better
>> than a video :-) ).
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>
>
>
> --
> Raffi Holzer
> Product Manager
> Pivotal Labs
>

Re: [pgadmin-hackers] Driver Module

2017-01-11 Thread Robert Eckhardt 
On Wed, Jan 11, 2017 at 8:07 PM, Dave Page  wrote:

> Hi
>
> On Wed, Jan 11, 2017 at 10:24 PM, George Gelashvili
>  wrote:
> > Hi Dave,
> >
> > Thanks for the pointer.
> > We realized that many of the changes we would need to make for supporting
> > Greenplum would need to go where there is pg version checking throughout
> the
> > code. This is because unlike PPAS which mostly adds additional features,
> > Greenplum is based on postgres 8.3.
>
> Isn't Heikki fixing that for your next release?
>

The current release is 8.2, we aren't trying to make that work with
pgAdmin4. Heikki did a yeomans work and the next release will be based on
8.3. Future releases should be more than one Postgres version at a time but
there was a lot of cleanup to do before we could start the Postgres
merging.


>
> > It looks like much of the version checking logic is repeated at points
> where
> > the features are differentiated by postgres version.
> >
> > It might make sense at this point to refactor the way that feature
> flagging
> > is done to be a little bit more unified between server types and postgres
> > versions so that we could for example have logic along the lines of:
> >
> > feature_enablement = FeatureEnablement(postgres_flavor,
> postgres_version)
> >
> > #...
> >
> > if(feature_enablement.check_internal_triggers ):
> >   # feature call here
> >
> > and then in a feature enablement class, reference the various versions
> and
> > flavors of postgres.
> >
> > Any thoughts on this?
>
> I worry that the list of features would end up being huge - we're not
> just talking about basic things like whether DDL triggers are
> supported, but the catalog schema (e.g. procpid vs. pid in
> pg_stat_activity) and small things like whether a particular GUC can
> be set on a tablespace.
>
> Ultimately, you have to do a version check at some point though
> (unless you're proposing to do something similar to probing the DOM in
> a browser at runtime). Doesn't GP's version string contain additional
> info beyond '8.3'? In pgAdmin 3 we had a EdbMinimumVersion(int major,
> int minor) function in the connection class that basically did:
>
> return isEdb && BackendMinimumVersion(x, y);
>
> Something like that could check other elements of the GP version number.
>

Greenplum is about to start leveraging semantic versioning. The version
number for the next release will be 5.0.0.


>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
> --
> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-hackers
>