[pgadmin-hackers] [PATCH] extract function from sqleditor

2017-06-05 Thread George Gelashvili
Hello Hackers!

Re. https://www.postgresql.org/message-id/CAFS4TJb-
7VTQQrnOi0g6MaoxMfEK9LzCds2yG%2BByS-mLHwydQA%40mail.gmail.com

We extracted the function bound to onSelectedRangesChanged from sqleditor!

- we read through the existing implementation and wrapped it in
`web/regression/javascript/selection/set_staged_rows_spec.js`
- we made some changes for clarity

Thanks,
Joao and George
diff --git a/web/pgadmin/static/js/selection/set_staged_rows.js 
b/web/pgadmin/static/js/selection/set_staged_rows.js
new file mode 100644
index ..cace7282
--- /dev/null
+++ b/web/pgadmin/static/js/selection/set_staged_rows.js
@@ -0,0 +1,114 @@
+/
+//
+// pgAdmin 4 - PostgreSQL Tools
+//
+// Copyright (C) 2013 - 2017, The pgAdmin Development Team
+// This software is released under the PostgreSQL Licence
+//
+//
+
+define(
+  [
+'jquery',
+'underscore'
+  ],
+  function ($, _) {
+function disableButton(selector) {
+  $(selector).prop('disabled', true);
+}
+
+function enableButton(selector) {
+  $(selector).prop('disabled', false);
+}
+
+function getRowPrimaryKeyValuesToStage(selectedRows, 
primaryKeyColumnIndices, gridData) {
+  return _.reduce(selectedRows, function (primaryKeyValuesToStage, 
dataGridRowIndex) {
+var gridRow = gridData[dataGridRowIndex];
+
+if (isRowMissingPrimaryKeys(gridRow, primaryKeyColumnIndices)) {
+  return primaryKeyValuesToStage;
+}
+
+var tempPK = gridRow.__temp_PK;
+primaryKeyValuesToStage[tempPK] = 
getSingleRowPrimaryKeyValueToStage(primaryKeyColumnIndices, gridRow);
+
+return primaryKeyValuesToStage;
+  }, {});
+}
+
+function isRowMissingPrimaryKeys(gridRow, primaryKeyColumnIndices) {
+  if (_.isUndefined(gridRow)) {
+return true;
+  }
+
+  return !_.isUndefined(
+_.find(primaryKeyColumnIndices, function (pkIndex) {
+  return _.isUndefined(gridRow[pkIndex]);
+})
+  );
+}
+
+function getSingleRowPrimaryKeyValueToStage(primaryKeyColumnIndices, 
gridRow) {
+  var rowToStage = {};
+  if (primaryKeyColumnIndices.length) {
+_.each(_.keys(gridRow), function (columnPos) {
+  if (_.contains(primaryKeyColumnIndices, Number(columnPos)))
+rowToStage[columnPos] = gridRow[columnPos];
+})
+  }
+  return rowToStage;
+}
+
+function getPrimaryKeysForSelectedRows(self, selectedRows) {
+  var primaryKeyColumnIndices = _.map(_.keys(self.keys), function 
(columnName) {
+var columnInfo = _.findWhere(self.columns, {name: columnName});
+return columnInfo['pos'];
+  });
+
+  var gridData = self.grid.getData();
+  var stagedRows = getRowPrimaryKeyValuesToStage(selectedRows, 
primaryKeyColumnIndices, gridData);
+
+  return stagedRows;
+}
+
+var setStagedRows = function (e, args) {
+  var self = this;
+
+  function setStagedRows(rowsToStage) {
+self.editor.handler.data_store.staged_rows = rowsToStage;
+  }
+
+  function isEditMode() {
+return self.editor.handler.can_edit;
+  }
+
+  disableButton('#btn-delete-row');
+  disableButton('#btn-copy-row');
+
+  if (!_.has(this.selection, 'getSelectedRows')) {
+setStagedRows({});
+return;
+  }
+
+  var selectedRows = this.selection.getSelectedRows();
+
+  if (selectedRows.length > 0) {
+var stagedRows = getPrimaryKeysForSelectedRows(self, selectedRows);
+setStagedRows(stagedRows);
+if (_.isEmpty(stagedRows)) {
+  this.selection.setSelectedRows([]);
+}
+
+enableButton('#btn-copy-row');
+if (isEditMode()) {
+  enableButton('#btn-delete-row');
+}
+  } else {
+setStagedRows({});
+  }
+};
+return setStagedRows;
+  }
+);
+
+
diff --git a/web/pgadmin/tools/sqleditor/templates/sqleditor/js/sqleditor.js 
b/web/pgadmin/tools/sqleditor/templates/sqleditor/js/sqleditor.js
index 597c4367..c83d1b36 100644
--- a/web/pgadmin/tools/sqleditor/templates/sqleditor/js/sqleditor.js
+++ b/web/pgadmin/tools/sqleditor/templates/sqleditor/js/sqleditor.js
@@ -4,6 +4,7 @@ define(
 'backbone', 'backgrid', 'codemirror', 'pgadmin.misc.explain',
 'sources/selection/grid_selector', 'sources/selection/clipboard',
 'sources/selection/copy_data',
+'sources/selection/set_staged_rows',
 
 'slickgrid', 'bootstrap', 'pgadmin.browser', 'wcdocker',
 'codemirror/mode/sql/sql', 'codemirror/addon/selection/mark-selection',
@@ -27,7 +28,7 @@ define(
 'slickgrid/slick.grid'
   ],
   function(
-$, _, S, alertify, pgAdmin, Backbone, Backgrid, CodeMirror, pgExplain, 
GridSelector, clipboard, copyData
+$, _, S, alertify, pgAdmin, Backbone, Backgrid, CodeMirror, pgExplain, 
GridSelector, clipboard, copyData, setStagedRows
   ) {
 

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

Re: [pgadmin-hackers] Re: [pgAdmin4][Patch][Feature #1971]: Remember column sizes between executions of the same query in the query tool

2017-06-05 Thread Shruti B Iyer
Hi Surinder!

We reviewed this patch. The changes look good and we especially like that
you have extracted out the new utility functions and the epicRandomString
function too.

This patch will likely affect the Query Results patch that is currently
under review
.
In order to assist either us or yourself when making a merge between these
patches, it would help to have jasmine unit testing for the two new
functions, getHash and calculate_column_width.

Also, we suggest that you rename calculate_column_width to
calculateColumnWidth for consistency with javascript code style.

Thanks,
Shruti and Matt

On Mon, Jun 5, 2017 at 9:16 AM Surinder Kumar <
surinder.ku...@enterprisedb.com> wrote:

> Staged changes are missed in previous patch, so please ignore.
> Please find attached updated patch.
>
> On Mon, Jun 5, 2017 at 4:29 PM, Surinder Kumar <
> surinder.ku...@enterprisedb.com> wrote:
>
>> Hi
>>
>> This patch contains two fixes:
>>
>> 1) In Query/tool or Edit grid, the width of table column header is fixed
>> depending on the column type(int, boolean, char etc.) due to which the
>> column name or type appears cut from right and doesn't looks good from user
>> point of view. The main concern was to display as much as the content of
>> column should be displayed.
>>
>> Now the width of column is decided using the text length of column name
>> or column type so that the column takes exact width it required and it
>> don't appears cut.
>>
>> 2) Remember column size after re-running a query.
>>
>> The approach is to extract table name from the query executed and use it
>> to store its columns width.
>> Whenever the column(s) width of a table is adjusted, the corresponding
>> values are updated into the object and used every time the same query is
>> executed.
>>
>> If a query is executed for e.g:
>>
>> SELECT generate_series(1, 1000) as id, generate_series(1, 1000) as name,
>> generate_series(1, 1000) as age
>>
>> ​it ​
>> displays 3 columns
>> ​but don't have any table name. In that case,
>>  i use a hash generator function which returns unique hash for a query
>> written in query editor and adjusted column(s) width are stored against
>> that hash in object.
>>
>> Is there any way to get temporary table name(avoiding unique hash) for
>> such queries ?​
>>
>> Also, Moved utilities functions into pgadmin/static/utils.js
>>
>> Please find attached patch and review.
>>
>> Thanks,
>> Surinder Kumar
>>
>
>
> --
> 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-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 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 

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

[pgadmin-hackers] pgAdmin 4 commit: Display and allow toggling of trigger enable/disable

2017-06-05 Thread Dave Page
Display and allow toggling of trigger enable/disable status from the trigger 
dialogue. Fixes #2386

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=9e98ded06c2c80968522db1c731e941a5b8d5f32

Modified Files
--
.../templates/trigger/sql/default/create.sql   |  2 +-
.../templates/trigger/sql/default/update.sql   |  8 --
.../databases/schemas/tables/triggers/__init__.py  | 30 +-
.../triggers/templates/trigger/js/trigger.js   | 10 +++-
4 files changed, 35 insertions(+), 15 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] [pgAdmin4][Patch] To display proper SQL for Procedure node

2017-06-05 Thread Dave Page
Thanks, patch applied.

On Tue, May 30, 2017 at 10:13 AM, Murtuza Zabuawala
 wrote:
> Hi,
>
> PFA patch to fix to display procedure options like IMMUTABLE STRICT SECURITY
> DEFINER PARALLEL RESTRICTED in SQL (Reverse Engineered).
> RM#2280
>
> --
> Regards,
> Murtuza Zabuawala
> EnterpriseDB: 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
>



-- 
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] pgAdmin 4 commit: Handle procedure flags (IMMUTABLE STRICT SECURITY DEF

2017-06-05 Thread Dave Page
Handle procedure flags (IMMUTABLE STRICT SECURITY DEFINER PARALLEL RESTRICTED) 
properly in RE-SQL on EPAS. Fixes #2280

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=3f150f3f4ec395e62db3f51accb601539863b5f1
Author: Murtuza Zabuawala 

Modified Files
--
.../servers/databases/schemas/functions/__init__.py|  5 +
.../functions/templates/procedure/ppas/sql/9.5_plus/create.sql |  7 +++
.../functions/templates/procedure/ppas/sql/9.6_plus/create.sql | 10 ++
3 files changed, 14 insertions(+), 8 deletions(-)


-- 
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] pgAdmin 4 commit: Cache statistics more reliably. Fixes #2357

2017-06-05 Thread Dave Page
Cache statistics more reliably. Fixes #2357

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=a4d86d24e6e664075d85461d816504c9d322f648
Author: Murtuza Zabuawala 

Modified Files
--
web/pgadmin/misc/statistics/static/js/statistics.js | 8 ++--
1 file changed, 6 insertions(+), 2 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] Declarative partitioning in pgAdmin4

2017-06-05 Thread Dave Page
Hi

On Mon, Jun 5, 2017 at 4:34 PM, Shirley Wang  wrote:

> Hi!
>
> Here's a summary of the interviews thus far:
>
> DBAs tend to create a partition strategy based on their experience and
> some alignment on their end users goals (analysts, report writers, and app
> developers). Once that partition strategy is created, they are usually
> forced to iterate on that strategy later based on feedback from end users
> of what the usage pattern are.
>
> We've identified a couple workflows that are key in partitioning based on
> whether they are maintaining a successful strategy or iterating to improve
> the strategy.
>
> One workflow is for rollups, which is for maintaining partitions at
> different granularities as data ages. We've learned that older data is less
> acted upon than recent data so users group together older data for viewing
> purposes. The other workflow is for splits, which when users discover that
> the data isn't granular enough so a single partition is being leveraged too
> many times. Users need to then reevaluate their strategy and tune
> partitions.
>
> To reevaluate strategies, DBAs ask themselves a few questions
> - Is the partition stable?
> - Are the queries analysts, report writers, and app developers are writing
> getting the correct data?
> - Are the partitions organized in a way that analysts, report writers, and
> app developers are able to achieve their goals? (ex. goals for app
> developer might be fast query while goal for report writer might be ability
> to get data so they can turn out reports faster. Goals might be conflicting)
>
> There are two needs from DBAs in terms of tuning partitioning strategies
> (there are more but addressing these two will provide the most value to
> users). One is to modify one or more child partitions by adding indexes or
> other such things, and the other is to recreate the parent table because
> there is inheritance to consider.
>

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.

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

Re: [pgadmin-hackers] Declarative partitioning in pgAdmin4

2017-06-05 Thread Shirley Wang
Hi!

Here's a summary of the interviews thus far:

DBAs tend to create a partition strategy based on their experience and some
alignment on their end users goals (analysts, report writers, and app
developers). Once that partition strategy is created, they are usually
forced to iterate on that strategy later based on feedback from end users
of what the usage pattern are.

We've identified a couple workflows that are key in partitioning based on
whether they are maintaining a successful strategy or iterating to improve
the strategy.

One workflow is for rollups, which is for maintaining partitions at
different granularities as data ages. We've learned that older data is less
acted upon than recent data so users group together older data for viewing
purposes. The other workflow is for splits, which when users discover that
the data isn't granular enough so a single partition is being leveraged too
many times. Users need to then reevaluate their strategy and tune
partitions.

To reevaluate strategies, DBAs ask themselves a few questions
- Is the partition stable?
- Are the queries analysts, report writers, and app developers are writing
getting the correct data?
- Are the partitions organized in a way that analysts, report writers, and
app developers are able to achieve their goals? (ex. goals for app
developer might be fast query while goal for report writer might be ability
to get data so they can turn out reports faster. Goals might be conflicting)

There are two needs from DBAs in terms of tuning partitioning strategies
(there are more but addressing these two will provide the most value to
users). One is to modify one or more child partitions by adding indexes or
other such things, and the other is to recreate the parent table because
there is inheritance to consider.

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

Re: [pgadmin-hackers] Style guide live website - looking for feedback

2017-06-05 Thread Dave Page
On Wed, May 31, 2017 at 7:39 PM, Shirley Wang  wrote:
> Hi all,
>
> We've started compiling some of the agreed upon styles into a site that is
> accessible for all developers.
>
> Link to the site: http://pgadmin4-styleguide.cfapps.io/index.html
>
> As of now, we have colors, type, and alerts documented. Other styles will be
> added and where the style guide lives will change sometime in the future.
>
> I'm currently looking for feedback on a few things:
> 1. how it's structured - does the navigation make sense?
> 2. the info provided on each page - are you as a developer able to find the
> info you need? is there anything missing?
> 3. usage - what will make this easier for you to use?
>
> Thanks!
>
> Here's the thread for style guide conversation:
> https://www.postgresql.org/message-id/flat/CAPG3WN4-KTS0p6rRPxpXNqY8az%2BSw8NQHfjx%2BRFYc8ZqB_00TQ%40mail.gmail.com#capg3wn4-kts0p6rrpxpxnqy8az+sw8nqhfjx+rfyc8zqb_0...@mail.gmail.com

Looks good. A couple of thoughts:

- Please use "pgAdmin 4" consistently :-)

- The neutral message panel has a border that is quite visible, whilst
the others have much more subtle borders. Seems like something to fix.

- I think we need some notes on when the different font sizes should be used.

- You've obviously created classes for these styles (e.g. text-14).
Let's make sure they are all actually defined in the stylesheets for
the app before we add the style guide :-)

Thanks!

-- 
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] Re: [pgAdmin4][Patch][Feature #1971]: Remember column sizes between executions of the same query in the query tool

2017-06-05 Thread Surinder Kumar
Staged changes are missed in previous patch, so please ignore.
Please find attached updated patch.

On Mon, Jun 5, 2017 at 4:29 PM, Surinder Kumar <
surinder.ku...@enterprisedb.com> wrote:

> Hi
>
> This patch contains two fixes:
>
> 1) In Query/tool or Edit grid, the width of table column header is fixed
> depending on the column type(int, boolean, char etc.) due to which the
> column name or type appears cut from right and doesn't looks good from user
> point of view. The main concern was to display as much as the content of
> column should be displayed.
>
> Now the width of column is decided using the text length of column name or
> column type so that the column takes exact width it required and it don't
> appears cut.
>
> 2) Remember column size after re-running a query.
>
> The approach is to extract table name from the query executed and use it
> to store its columns width.
> Whenever the column(s) width of a table is adjusted, the corresponding
> values are updated into the object and used every time the same query is
> executed.
>
> If a query is executed for e.g:
>
> SELECT generate_series(1, 1000) as id, generate_series(1, 1000) as name,
> generate_series(1, 1000) as age
>
> ​it ​
> displays 3 columns
> ​but don't have any table name. In that case,
>  i use a hash generator function which returns unique hash for a query
> written in query editor and adjusted column(s) width are stored against
> that hash in object.
>
> Is there any way to get temporary table name(avoiding unique hash) for
> such queries ?​
>
> Also, Moved utilities functions into pgadmin/static/utils.js
>
> Please find attached patch and review.
>
> Thanks,
> Surinder Kumar
>


Feature_1971.patch
Description: Binary data

-- 
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] [pgAdmin4][Patch][Feature #1971]: Remember column sizes between executions of the same query in the query tool

2017-06-05 Thread Surinder Kumar
Hi

This patch contains two fixes:

1) In Query/tool or Edit grid, the width of table column header is fixed
depending on the column type(int, boolean, char etc.) due to which the
column name or type appears cut from right and doesn't looks good from user
point of view. The main concern was to display as much as the content of
column should be displayed.

Now the width of column is decided using the text length of column name or
column type so that the column takes exact width it required and it don't
appears cut.

2) Remember column size after re-running a query.

The approach is to extract table name from the query executed and use it to
store its columns width.
Whenever the column(s) width of a table is adjusted, the corresponding
values are updated into the object and used every time the same query is
executed.

If a query is executed for e.g:

SELECT generate_series(1, 1000) as id, generate_series(1, 1000) as name,
generate_series(1, 1000) as age

​it ​
displays 3 columns
​but don't have any table name. In that case,
 i use a hash generator function which returns unique hash for a query
written in query editor and adjusted column(s) width are stored against
that hash in object.

Is there any way to get temporary table name(avoiding unique hash) for such
queries ?​

Also, Moved utilities functions into pgadmin/static/utils.js

Please find attached patch and review.

Thanks,
Surinder Kumar


Feature_1971.patch
Description: Binary data

-- 
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] [pgAdmin4][PATCH] To fix the issue in Synonym node EPAS9.2

2017-06-05 Thread Murtuza Zabuawala
Hi,

PFA patch to fix the issue in Synonym node for EPAS9.2+ where Packages are
not displaying as a  target objects.
RM#1813

--
Regards,
Murtuza Zabuawala
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
diff --git 
a/web/pgadmin/browser/server_groups/servers/databases/schemas/synonyms/templates/synonym/sql/9.2_plus/get_objects.sql
 
b/web/pgadmin/browser/server_groups/servers/databases/schemas/synonyms/templates/synonym/sql/9.2_plus/get_objects.sql
new file mode 100644
index 000..0ae7aec
--- /dev/null
+++ 
b/web/pgadmin/browser/server_groups/servers/databases/schemas/synonyms/templates/synonym/sql/9.2_plus/get_objects.sql
@@ -0,0 +1,56 @@
+{###}
+{### If Target Type is Function ###}
+{###}
+{% if trgTyp == 'f' %}
+SELECT DISTINCT proname AS name
+FROM pg_proc p, pg_namespace n
+WHERE p.pronamespace = n.oid AND
+n.nspname = {{  trgSchema|qtLiteral }} AND
+p.protype  = '0'
+ORDER BY proname;
+{###}
+{### If Target Type is Procedure ###}
+{###}
+{% elif trgTyp == 'p' %}
+SELECT DISTINCT proname AS name
+FROM pg_proc p, pg_namespace n
+WHERE p.pronamespace = n.oid AND
+n.nspname = {{  trgSchema|qtLiteral }} AND
+p.protype  = '1'
+ORDER BY proname;
+{###}
+{### If Target Type is Synonym ###}
+{###}
+{% elif trgTyp == 's' %}
+SELECT synname AS name
+FROM pg_synonym
+ORDER BY synname;
+{###}
+{### If Target Type is Package ###}
+{###}
+{% elif trgTyp == 'P' %}
+SELECT nspname AS name
+FROM pg_namespace
+WHERE nspparent IN (
+SELECT oid
+FROM pg_namespace
+WHERE nspname = {{ trgSchema|qtLiteral }} LIMIT 1
+   )
+  AND nspobjecttype = 0
+ORDER BY nspname;
+{% else %}
+{###}
+{### If Target Type is Table/View/M.View/Sequnce ###}
+{###}
+SELECT relname AS name
+FROM pg_class c, pg_namespace n
+WHERE c.relnamespace = n.oid AND
+n.nspname = {{  trgSchema|qtLiteral }} AND
+{% if trgTyp == 'v' %}
+{# If view is select then we need to fetch both view and materialized view #}
+ (c.relkind = 'v' OR c.relkind = 'm')
+{% else %}
+c.relkind = {{ trgTyp|qtLiteral }}
+{% endif %}
+ORDER BY relname;
+{% endif %}
\ No newline at end of file
diff --git 
a/web/pgadmin/browser/server_groups/servers/databases/schemas/synonyms/templates/synonym/sql/9.2_plus/properties.sql
 
b/web/pgadmin/browser/server_groups/servers/databases/schemas/synonyms/templates/synonym/sql/9.2_plus/properties.sql
new file mode 100644
index 000..ec2724a
--- /dev/null
+++ 
b/web/pgadmin/browser/server_groups/servers/databases/schemas/synonyms/templates/synonym/sql/9.2_plus/properties.sql
@@ -0,0 +1,31 @@
+SELECT synname AS name, pg_get_userbyid(synowner) AS owner,
+  synobjschema, synobjname,  ns.nspname as schema,
+  COALESCE(
+  (SELECT relkind
+  FROM pg_class c, pg_namespace n
+  WHERE c.relnamespace = n.oid
+AND n.nspname = synobjschema
+AND c.relname = synobjname),
+  -- For Function/Procedure
+  (SELECT CASE WHEN p.protype = '0' THEN 'f'::"char" ELSE 'p'::"char" END
+  FROM pg_proc p, pg_namespace n
+WHERE p.pronamespace = n.oid
+  AND n.nspname = synobjschema
+  AND p.proname = synobjname LIMIT 1),
+  -- For Package
+  (SELECT CASE WHEN count(*) > 0 THEN 'P'::"char" END
+  FROM pg_namespace
+WHERE nspparent IN (SELECT oid
+   FROM pg_namespace
+WHERE nspname = synobjschema LIMIT 1)
+  AND nspname = synobjname
+  AND nspobjecttype = 0),
+  -- Default s = Synonym
+  's') AS targettype,
+  CASE WHEN ns.nspname = 'public' THEN true ELSE false END AS is_public_synonym
+FROM pg_synonym s  JOIN pg_namespace ns ON s.synnamespace = ns.oid
+ WHERE s.synnamespace={{scid}}::oid
+ {% if syid %}
+   AND s.synname={{ syid|qtLiteral }}
+ {% endif %}
+ORDER BY synname;
\ No newline at end of file

-- 
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] [pgAdmin4][Patch]: Fixed RM 2381 - "Create Script" for view assigns incorrect schema to trigger functions in "public" schema.

2017-06-05 Thread Khushboo Vashi
Hi,

Please find the attached patch to fix RM 2381: "Create Script" for view
assigns incorrect schema to trigger functions in "public" schema.

Fixed the trigger function schema name in the view SQL tab.


Thanks,
Khushboo
diff --git a/web/pgadmin/browser/server_groups/servers/databases/schemas/views/__init__.py b/web/pgadmin/browser/server_groups/servers/databases/schemas/views/__init__.py
index 836018b..17a7df6 100644
--- a/web/pgadmin/browser/server_groups/servers/databases/schemas/views/__init__.py
+++ b/web/pgadmin/browser/server_groups/servers/databases/schemas/views/__init__.py
@@ -896,15 +896,26 @@ class ViewNode(PGChildNodeView, VacuumSettings):
 trigger['oid'], columns)
 res_rows = trigger_definition(res_rows)
 
-res_rows['schema'] = res_rows['nspname']
-
 # It should be relname and not table, but in create.sql
 # (which is referred from many places) we have used
 # data.table and not data.relname so compatibility add new key as
 # table in res_rows.
 res_rows['table'] = res_rows['relname']
 
-res_rows['tfunction'] = self.qtIdent(self.conn, res_rows['schema'], res_rows['tfunction'])
+# Get trigger function with its schema name
+SQL = render_template("/".join([self.trigger_temp_path,
+'sql/#{0}#/get_triggerfunctions.sql'.format(self.manager.version)]),
+  tgfoid=res_rows['tgfoid'],
+  show_system_objects=self.blueprint.show_system_objects)
+
+status, result = self.conn.execute_dict(SQL)
+if not status:
+return internal_server_error(errormsg=result)
+
+# Update the trigger function which we have fetched with schema name
+if 'rows' in result and len(result['rows']) > 0 and \
+'tfunctions' in result['rows'][0]:
+res_rows['tfunction'] = result['rows'][0]['tfunctions']
 
 # Format arguments
 if len(res_rows['custom_tgargs']) > 1:

-- 
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]: Load module's JS files only when required

2017-06-05 Thread Surinder Kumar
Hi Dave,

Please find attached patch for minifying CSS files and optimize images
using Webpack.

*Steps to run:*

1) After applying patch, go to web directory and run npm install on
terminal to install packages which are used to parse/minify CSS files.

2) Run npm run build which creates dist folder inside web/pgadmin/static/
directory to store processed images, fonts and css files.

3. Set DEBUG = False in config_local.py and then run python pgAdmin.py to
start server.
I kept generated main.css and overrides.css conditional in base.html to
load them only when debug mode is False


After running "npm run build", following files/directories are generated:

1) main.css -  about 20 vendor CSS files are packed into this file and more
importantly the paths to images are preserved.

2) overrides.css - it contains bootstrap.overrides.css and pgadmin.css,
they has to be packed separately and loaded after all CSS files are loaded
because the purpose of these files is to override the vendor or modules css.

3) img - it contains the images used in CSS files. The name of image files
can also be hashed names for caching purpose which we can use.

4) fonts - it contains the fonts used in fontawesome.css and other css
files.

This is a simple patch to demonstrate how CSS files will be minified with
Webpack.

For now it minifies only vendor CSS files, I will add modules static files
in the list later on.

Any thoughts on minifying template CSS files which are built dynamically
and loaded with dependency on other modules?

Also, I looked into Flask-webpack which generates bundled assets using
Webpack(webpack.config.js) and provide additionally global template tags to
use in Jinja templates.

But it might not work with latest version of Webpack as this repo is not
updated since last 2 years. I need to check with latest version and I will
update on this.


Thanks
Surinder


On Mon, May 29, 2017 at 5:45 AM, Dave Page  wrote:

> On Fri, May 26, 2017 at 12:01 AM, Surinder Kumar
>  wrote:
> > On Fri, May 26, 2017 at 3:02 AM, Dave Page  wrote:
> >>
> >> On Tue, May 23, 2017 at 4:21 PM, Dave Page  wrote:
> >> >
> >> > I'm actually thinking that maybe it would be easier to start with the
> >> > CSS files
> >>
> >> Which i did yesterday. However, it soon became obvious that that isn't
> >> so easy either, as the CSS files contain url references which need to
> >> be adjusted, which isn't trivial.
> >>
> >> However, I did find a flask-webpack module, which looks interesting:
> >>
> >> https://github.com/nickjj/flask-webpack
> >> https://nickjanetakis.com/blog/manage-your-assets-with-flask-webpack
> >>
> >> Surinder; when you have some free time, could you look into a simple
> >> PoC with the CSS files using that please?
> >
> > Ok. I will look
>
> BTW; if it looks like it will take a while to implement (as I
> suspect), we should consider polishing off your initial patch as an
> interim step. Any thoughts on how long RM2424 would take to resolve?
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>


bundle_css_using_webpack.patch
Description: Binary data

-- 
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-05 Thread Dave Page
On Fri, Jun 2, 2017 at 9:01 AM, Akshay Joshi 
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 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
>>
>
>
>
> --
> *Akshay Joshi*
> *Principal Software Engineer *
>
>
>
> *Phone: +91 20-3058-9517 <+91%2020%203058%209517>Mobile: +91 976-788-8246
> <+91%2097678%2088246>*
>
>
> --
> 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


Re: [pgadmin-hackers] [pgAdmin4][Patch]: Fixed RM 2324 - PostGIS datatypes not showing up properly on SQL tab.

2017-06-05 Thread Khushboo Vashi
Hi,

Fixed PostGIS datatype on SQL tab for Table, column, Foreign Table and Type
node.

Please find the attached updated patch.


Thanks,
Khushboo

On Thu, Jun 1, 2017 at 6:36 PM, Murtuza Zabuawala <
murtuza.zabuaw...@enterprisedb.com> wrote:

>
> On Thu, Jun 1, 2017 at 5:27 PM, Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>> Hi,
>>
>>
>> On Thu, Jun 1, 2017 at 4:57 PM, Murtuza Zabuawala <
>> murtuza.zabuaw...@enterprisedb.com> wrote:
>>
>>> Hi Khushboo,
>>>
>>> Please include Type node and Foreign Table node in your fix :-)
>>>
>>> I don't think Type node requires this change.
>>
>> Yes, It do require because user can create composite type from existing
> types.
> [image: Inline image 1]
>
>> Foreign table changes added in the attached updated patch.
>>
>>> --
>>>
>> Thanks Murtuza for pointing this out.


> Regards,
>>> Murtuza Zabuawala
>>> EnterpriseDB: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>>
>>> On Thu, Jun 1, 2017 at 3:23 PM, Khushboo Vashi <
>>> khushboo.va...@enterprisedb.com> wrote:
>>>
 Hi,

 Please find the attached patch to fix RM #2324 : PostGIS datatypes not
 showing up properly on SQL tab.

 Thanks,
 Khushboo



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


>>>
>>
>
diff --git a/web/pgadmin/browser/server_groups/servers/databases/schemas/foreign_tables/__init__.py b/web/pgadmin/browser/server_groups/servers/databases/schemas/foreign_tables/__init__.py
index 15455e8..2ee6a43 100644
--- a/web/pgadmin/browser/server_groups/servers/databases/schemas/foreign_tables/__init__.py
+++ b/web/pgadmin/browser/server_groups/servers/databases/schemas/foreign_tables/__init__.py
@@ -830,7 +830,7 @@ class ForeignTableView(PGChildNodeView, DataTypeReader):
 data['columns'] = col_data
 
 SQL = render_template("/".join([self.template_path,
-'create.sql']), data=data)
+'create.sql']), data=data, is_sql=True)
 
 sql_header = u"""-- FOREIGN TABLE: {0}
 
@@ -1093,10 +1093,10 @@ class ForeignTableView(PGChildNodeView, DataTypeReader):
 substr = c['fulltype'][c['fulltype'].find("(") + 1:c['fulltype'].find(")")]
 typlen = substr.split(",")
 if len(typlen) > 1:
-c['typlen'] = int(typlen[0])
-c['precision'] = int(typlen[1])
+c['typlen'] = int(typlen[0]) if typlen[0].isdigit() else typlen[0]
+c['precision'] = int(typlen[1]) if typlen[1].isdigit() else typlen[1]
 else:
-c['typlen'] = int(typlen[0])
+c['typlen'] = int(typlen[0]) if typlen[0].isdigit() else typlen[0]
 c['precision'] = None
 
 # Get formatted Column Options
diff --git a/web/pgadmin/browser/server_groups/servers/databases/schemas/foreign_tables/templates/foreign_tables/sql/9.2_plus/create.sql b/web/pgadmin/browser/server_groups/servers/databases/schemas/foreign_tables/templates/foreign_tables/sql/9.2_plus/create.sql
index cbffa89..d055de0 100644
--- a/web/pgadmin/browser/server_groups/servers/databases/schemas/foreign_tables/templates/foreign_tables/sql/9.2_plus/create.sql
+++ b/web/pgadmin/browser/server_groups/servers/databases/schemas/foreign_tables/templates/foreign_tables/sql/9.2_plus/create.sql
@@ -4,7 +4,7 @@
 CREATE FOREIGN TABLE {{ conn|qtIdent(data.basensp, data.name) }}(
 {% if data.columns %}
 {% for c in data.columns %}
-{{conn|qtIdent(c.attname)}} {{conn|qtTypeIdent(c.datatype) }}{% if c.typlen %}({{c.typlen}}{% if c.precision %}, {{c.precision}}{% endif %}){% endif %}{% if c.isArrayType %}[]{% endif %}{% if c.coloptions %}
+{{conn|qtIdent(c.attname)}} {% if is_sql %}{{ c.fulltype }}{% else %}{{conn|qtTypeIdent(c.datatype) }}{% if c.typlen %}({{c.typlen}}{% if c.precision %}, {{c.precision}}{% endif %}){% endif %}{% if c.isArrayType %}[]{% endif %}{% endif %}{% if c.coloptions %}
 {% for o in c.coloptions %}{% if o.option and o.value %}
 {% if loop.first %} OPTIONS ({% endif %}{% if not loop.first %}, {% endif %}{{o.option}} {{o.value|qtLiteral}}{% if loop.last %}){% endif %}{% endif %}
 {% endfor %}{% endif %}{% if c.attnotnull %}
diff --git a/web/pgadmin/browser/server_groups/servers/databases/schemas/foreign_tables/templates/foreign_tables/sql/9.5_plus/create.sql b/web/pgadmin/browser/server_groups/servers/databases/schemas/foreign_tables/templates/foreign_tables/sql/9.5_plus/create.sql
index 093eec0..bccebd4 100644
--- a/web/pgadmin/browser/server_groups/servers/databases/schemas/foreign_tables/templates/foreign_tables/sql/9.5_plus/create.sql
+++ b/web/pgadmin/browser/server_groups/servers/databases/schemas/foreign_tables/templates/foreign_tables/sql/9.5_plus/create.sql
@@ -7,7 +7,7 @@ 

[pgadmin-hackers] [pgAdmin4][PATCH] To fix the issue in procedure debugging in EPAS

2017-06-05 Thread Murtuza Zabuawala
Hi,

PFA patch to fix the issue where debugger module is not throwing proper
error for unsupported argument mode type in procedure.
RM#1466

@Neel,
Can you please do quick review of this patch?

--
Regards,
Murtuza Zabuawala
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
diff --git a/web/pgadmin/tools/debugger/__init__.py 
b/web/pgadmin/tools/debugger/__init__.py
index 2c0dbc4..79e5eae 100644
--- a/web/pgadmin/tools/debugger/__init__.py
+++ b/web/pgadmin/tools/debugger/__init__.py
@@ -197,6 +197,15 @@ def init_function(node_type, sid, did, scid, fid, 
trid=None):
 elif ppas_server and 
r_set['rows'][0]['prosrc'].lstrip().startswith('$__EDBwrapped__$'):
 ret_status = False
 msg = gettext("EDB Advanced Server wrapped functions cannot be 
debugged.")
+# We cannot debug if PPAS and argument mode is VARIADIC
+elif ppas_server and r_set['rows'][0]['lanname'] == 'edbspl' and \
+r_set['rows'][0]['proargmodes'] is not None and \
+'v' in r_set['rows'][0]['proargmodes']:
+ret_status = False
+msg = gettext(
+"An 'edbspl' target with a variadic argument is not supported"
+" and cannot be debugged."
+)
 else:
 # If user is super user then we should check debugger library is 
loaded or not
 if user['is_superuser']:

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