Re: [pgAdmin][4709] Invalid FTS configuration token dictionaries

[Akshay Joshi]

Hi Ganesh

As per my understanding, the dictionary names from "pg_catalog" should not
be schema-qualified. Please make appropriate changes and send the patch
again.

@Dave/@Ashesh thoughts?


On Tue, Apr 14, 2020 at 5:37 PM Ganesh Jaybhay <
ganesh.jayb...@enterprisedb.com> wrote:

> Hi Hackers,
>
> Attached is the patch to add schema qualified dictionary names in FTS
> configuration to overcome the confusion of duplicate dictionary names.
>
> Also modified the resql test cases accordingly.
>
> Please review.
>
> Regards,
> Ganesh Jaybhay
>


-- 
*Thanks & Regards*
*Akshay Joshi*

*Sr. Software Architect*
*EnterpriseDB Software India Private Limited*
*Mobile: +91 976-788-8246*

Re: [pgAdmin][4709] Invalid FTS configuration token dictionaries

[Dave Page]

On Wed, Apr 15, 2020 at 8:25 AM Akshay Joshi 
wrote:

> Hi Ganesh
>
> As per my understanding, the dictionary names from "pg_catalog" should not
> be schema-qualified. Please make appropriate changes and send the patch
> again.
>
> @Dave/@Ashesh thoughts?
>

Maybe I'm missing something, but I don't see why not. If anything, I'd
argue it's defensive programming, that makes good sense.


>
>
> On Tue, Apr 14, 2020 at 5:37 PM Ganesh Jaybhay <
> ganesh.jayb...@enterprisedb.com> wrote:
>
>> Hi Hackers,
>>
>> Attached is the patch to add schema qualified dictionary names in FTS
>> configuration to overcome the confusion of duplicate dictionary names.
>>
>> Also modified the resql test cases accordingly.
>>
>> Please review.
>>
>> Regards,
>> Ganesh Jaybhay
>>
>
>
> --
> *Thanks & Regards*
> *Akshay Joshi*
>
> *Sr. Software Architect*
> *EnterpriseDB Software India Private Limited*
> *Mobile: +91 976-788-8246*
>


-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: [pgAdmin][RM4946] Issue with temporary tables on commit drop as.

[Khushboo Vashi]

Hi Amol,

On Wed, Apr 15, 2020 at 12:06 PM Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

> Hi,
>
> I am reviewing this patch.
>
> Thanks,
> Khushboo
>
> On Wed, Apr 15, 2020 at 11:45 AM Amol Vyavahare <
> amol.vyavah...@enterprisedb.com> wrote:
>
>> Hi Hackers,
>> Attached is the patch to fix the Issue with temporary tables on commit
>> drop as. This patch fixes the issue where an error was thrown when the user
>> tried to create a temporary table via query tool and no result
>> was displayed when the query was executed.
>>
>> Please review.
>>
>> Please write the API test cases for the same even if the changes are very
small but they are in the SQL Editor backend code.
The patch is working fine and looks good to me.

Thanks,
Khushboo

> --
>> *Regards,*
>> *Amol Vyavahare*
>> *E**nterpriseDB Corporation*
>> The Enterprise Postgres Company
>> *T: +91 20 6644 9600, M: +91 738 738 2128*
>> [image: EDB Postgres] Unit 301 A, Third
>> Floor, Godrej Castlemaine,
>> 155, Sassoon Road, Pune, MH - 411001
>> [image: Blog Feed]  [image: Facebook]
>>  [image: Twitter]
>>  [image: LinkedIn]
>>  [image: Google+]
>> 
>> Website: www.enterprisedb.com
>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>
>>
>>
>>

Re: pgAdmin 4 - next gettext usage fixes

[Akshay Joshi]

Hi Aditya

I think the fix is incorrect. .format method should be applied after
gettext() like gettext().format(). Please check for other places too and
send the updated patch.

On Wed, Apr 15, 2020 at 11:38 AM Aditya Toshniwal <
aditya.toshni...@enterprisedb.com> wrote:

> Hi Hackers/Libor,
>
> The changes like below are incorrect. Try "Count rows" from a table's
> context menu.
>
> -info=gettext("Table rows counted: %s" % count),
>
> +info=gettext("Table rows counted: %s") % count,
>
> Attached is the patch to fix all such changes in pgAdmin, to use format()
> instead.
> Please review.
>
> On Fri, Apr 10, 2020 at 2:57 PM Akshay Joshi <
> akshay.jo...@enterprisedb.com> wrote:
>
>> Hi Libor
>>
>> Thanks, patch applied. Please make sure to run the PEP8 checks before
>> sending the patch.
>> I have fixed and committed the code.
>>
>> On Wed, Apr 8, 2020 at 9:30 PM Libor M.  wrote:
>>
>>> Hello,
>>> I fixed next gettext usage:
>>>
>>> - fixed gettext usage with .format() only for original text with %s
>>> - fixed typos
>>> - fixed translation yes/no buttons in dialog
>>> - improved translating sentences without "connecting" words (eg. see
>>> web/pgadmin/dashboard/static/js/dashboard.js, word 'cancel' needs to
>>> be translated in Czech language as 'zrušit' but in another sentence as
>>> 'zrušení')
>>> - added gettext for text translations
>>>
>>> Diff file is attached.
>>>
>>> Best regards,
>>>
>>> Libor M.
>>>
>>> E-mail: libor...@gmail.com
>>> GitHub: https://github.com/liborm85
>>>
>>
>>
>> --
>> *Thanks & Regards*
>> *Akshay Joshi*
>>
>> *Sr. Software Architect*
>> *EnterpriseDB Software India Private Limited*
>> *Mobile: +91 976-788-8246*
>>
>
>
> --
> Thanks and Regards,
> Aditya Toshniwal
> pgAdmin Hacker | Sr. Software Engineer | EnterpriseDB India | Pune
> "Don't Complain about Heat, Plant a TREE"
>


-- 
*Thanks & Regards*
*Akshay Joshi*

*Sr. Software Architect*
*EnterpriseDB Software India Private Limited*
*Mobile: +91 976-788-8246*

Re: [pgAdmin][RM3947] Fixes related rows copy-paste in Query Tool.

[Nagesh Dhope]

Please find an updated patch, which handles field separator and quote
character from *Result Grid *preferences.

On Wed, Apr 15, 2020 at 10:18 AM Nagesh Dhope 
wrote:

> Hi Hackers,
> Please find a patch which fixes,
>
>1. Copy table rows across two or more active query tool sessions.
>2. Copied rows can be pasted multiple times without selecting a row in
>the query tool grid.
>3. Adds an empty row at the end in the query tool grid after pasting
>rows.
>
> --
> Thanks,
> Nagesh
>


-- 
Thanks,
Nagesh


RM3947_v2.patch
Description: Binary data

pgAdmin 4 commit: Correct the build script whereby mistake we have remo

[Akshay Joshi]

Correct the build script whereby mistake we have removed the theme components 
from the source tree while building.

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=25553b11ed98f3af47f4f08b6a875f77056a513b
Author: Neel Patel 

Modified Files
--
pkg/mac/build.sh | 1 -
1 file changed, 1 deletion(-)

pgAdmin 4 commit: Fixed an issue where the mode is not shown in the pro

[Akshay Joshi]

Fixed an issue where the mode is not shown in the properties dialog of 
functions/procedures if all the arguments are IN arguments. Fixes #5387

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=8654d6cf4344f35a0999f1adf2b5965bdda3b283
Author: Shubham Agarwal 

Modified Files
--
docs/en_US/release_notes_4_21.rst  | 3 ++-
.../server_groups/servers/databases/schemas/functions/__init__.py  | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)

pgAdmin 4 commit: Fixed following issues for Procedures:

[Akshay Joshi]

Fixed following issues for Procedures:
  1) Change comments on the procedure with arguments as a procedure can be 
overloaded.
 Note that on EPAS servers, procedure overloading works only for v11+.
  2) The save button of a procedure dialog is enabled without any change.
  3) Fixed formatting of the reverse-engineered SQL.
  4) On EPAS servers, the parameters set were not displayed in the SQL 
generated.
 They are visible only if set to edbsql.
  5) Changing the volatility option of any existing procedure was not working.
  6) Changing the parallel option (EPAS v9.6+) was not working.
  7) Added RE-SQL test cases for procedures.

Fixes #4620, Fixes #4873

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=0424f7d962188a7373668ace58b56365017df6fd
Author: Aditya Toshniwal 

Modified Files
--
docs/en_US/release_notes_4_21.rst  |   2 +
.../databases/schemas/functions/__init__.py|  22 ++-
.../schemas/functions/static/js/procedure.js   |  10 +-
.../templates/procedures/pg/sql/11_plus/create.sql |   9 +-
.../templates/procedures/pg/sql/11_plus/update.sql |   2 +-
.../procedures/ppas/sql/11_plus/create.sql |  10 +-
.../procedures/ppas/sql/11_plus/update.sql |   2 +-
.../procedures/ppas/sql/9.5_plus/create.sql|   2 +-
.../procedures/ppas/sql/9.5_plus/update.sql|   5 +-
.../procedures/ppas/sql/9.6_plus/create.sql|   4 +-
.../procedures/ppas/sql/9.6_plus/properties.sql|  46 +
.../procedures/ppas/sql/9.6_plus/update.sql|   6 +-
.../tests/pg/11_plus/alter_proc_comment.sql|  13 ++
.../tests/pg/11_plus/alter_proc_comment_msql.sql   |   2 +
.../tests/pg/11_plus/alter_proc_param.sql  |  14 ++
.../tests/pg/11_plus/alter_proc_param_msql.sql |   2 +
.../tests/pg/11_plus/alter_ptrig_comment.sql   |  18 ++
.../tests/pg/11_plus/alter_ptrig_set_1.sql |  18 ++
.../tests/pg/11_plus/alter_ptrig_set_2.sql |  20 +++
.../tests/pg/11_plus/alter_ptrig_set_3.sql |  21 +++
.../tests/pg/11_plus/create_event_trigger_full.sql |  24 +++
.../tests/pg/11_plus/create_plain_trigger.sql  |  15 ++
.../tests/pg/11_plus/create_plain_trigger_full.sql |  25 +++
.../tests/pg/11_plus/create_procedure.sql  |  10 ++
.../tests/pg/11_plus/test_procedures.json  |  58 +++
.../tests/pg/11_plus/test_trigger_functions.json   | 191 +
.../tests/ppas/11_plus/alter_proc_comment.sql  |  13 ++
.../tests/ppas/11_plus/alter_proc_comment_msql.sql |   2 +
.../tests/ppas/11_plus/alter_proc_param.sql|  14 ++
.../tests/ppas/11_plus/alter_proc_param_msql.sql   |   2 +
.../tests/ppas/11_plus/alter_ptrig_comment.sql |  18 ++
.../tests/ppas/11_plus/alter_ptrig_set_1.sql   |  18 ++
.../tests/ppas/11_plus/alter_ptrig_set_2.sql   |  20 +++
.../tests/ppas/11_plus/alter_ptrig_set_3.sql   |  21 +++
.../ppas/11_plus/create_event_trigger_full.sql |  20 +++
.../tests/ppas/11_plus/create_plain_trigger.sql|  15 ++
.../ppas/11_plus/create_plain_trigger_full.sql |  21 +++
.../tests/ppas/11_plus/create_procedure.sql|  10 ++
.../tests/ppas/11_plus/test_procedures.json|  58 +++
.../tests/ppas/11_plus/test_trigger_functions.json | 171 ++
.../tests/ppas/9.6_plus/alter_proc_comment.sql |  14 ++
.../ppas/9.6_plus/alter_proc_comment_msql.sql  |   2 +
.../tests/ppas/9.6_plus/alter_proc_opt.sql |  15 ++
.../tests/ppas/9.6_plus/alter_proc_opt_msql.sql|  15 ++
.../tests/ppas/9.6_plus/alter_proc_param.sql   |  15 ++
.../tests/ppas/9.6_plus/alter_proc_param_msql.sql  |   2 +
.../tests/ppas/9.6_plus/alter_ptrig_comment.sql|  18 ++
.../tests/ppas/9.6_plus/alter_ptrig_set_1.sql  |  18 ++
.../tests/ppas/9.6_plus/alter_ptrig_set_2.sql  |  20 +++
.../tests/ppas/9.6_plus/alter_ptrig_set_3.sql  |  21 +++
.../ppas/9.6_plus/create_event_trigger_full.sql|  20 +++
.../tests/ppas/9.6_plus/create_plain_trigger.sql   |  15 ++
.../ppas/9.6_plus/create_plain_trigger_full.sql|  21 +++
.../tests/ppas/9.6_plus/create_procedure.sql   |  11 ++
.../tests/ppas/9.6_plus/test_procedures.json   |  71 
.../ppas/9.6_plus/test_trigger_functions.json  | 171 ++
.../tests/ppas/default/alter_proc_comment.sql  |  14 ++
.../tests/ppas/default/alter_proc_comment_msql.sql |   2 +
.../tests/ppas/default/alter_proc_opt.sql  |  15 ++
.../tests/ppas/default/alter_proc_opt_msql.sql |  15 ++
.../tests/ppas/default/alter_proc_param.sql|  15 ++
.../tests/ppas/default/alter_proc_param_msql.sql   |   2 +
.../tests/ppas/default/create_procedure.sql|  11 ++
.../tests/ppas/default/test_procedures.json|  71 
64 files changed, 1511 insertions(+), 37 deletions(-)

Re: [pgAdmin][RM4873] Change comment of a procedure with arguments

[Akshay Joshi]

Thanks, patch applied.

On Tue, Apr 14, 2020 at 5:52 PM Aditya Toshniwal <
aditya.toshni...@enterprisedb.com> wrote:

> Hi Hackers,
>
> Attached is a patch to fix following issues:
> 1) Change comment of procedure with arguments as a procedure can be
> overloaded. Note that on EPAS servers, procedure overloading works only for
> v11+ .
> 2) The save button of a procedure dialog is enabled without any change.
> Fixed.
> 3) Fixed formatting of the reverse engineered SQL.
> 4) On EPAS servers, parameters set were not displayed in the SQL
> generated. They are visible only if set to edbsql. Fixed.
> 5) Changing the volatility option of any existing procedure was not
> working. Fixed.
> 6) Changing the parallel option (EPAS v9.6+) was not working. Fixed.
> 7) Added RE-SQL test cases for procedures. Fixes #4620.
>
> Please review.
>
> --
> Thanks and Regards,
> Aditya Toshniwal
> pgAdmin Hacker | Sr. Software Engineer | EnterpriseDB India | Pune
> "Don't Complain about Heat, Plant a TREE"
>


-- 
*Thanks & Regards*
*Akshay Joshi*

*Sr. Software Architect*
*EnterpriseDB Software India Private Limited*
*Mobile: +91 976-788-8246*

Re: [pgAdmin4 - Bug #5387]

[Akshay Joshi]

Thanks, patch applied.

On Tue, Apr 14, 2020 at 4:01 PM Shubham Agarwal <
shubham.agar...@enterprisedb.com> wrote:

> Hi Team,
> PFA the patch for displaying mode in properties of func/proc if all args
> are "IN"
>
> --
> Thanks & Regards,
> Shubham Agarwal
> EnterpriseDB Corporation
>
> The Postgres Database Company
>


-- 
*Thanks & Regards*
*Akshay Joshi*

*Sr. Software Architect*
*EnterpriseDB Software India Private Limited*
*Mobile: +91 976-788-8246*

Re: [pgAdmin][RM4946] Issue with temporary tables on commit drop as.

[Amol Vyavahare]

Sure, will do that.

On Wed, Apr 15, 2020 at 1:33 PM Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

> Hi Amol,
>
> On Wed, Apr 15, 2020 at 12:06 PM Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>> Hi,
>>
>> I am reviewing this patch.
>>
>> Thanks,
>> Khushboo
>>
>> On Wed, Apr 15, 2020 at 11:45 AM Amol Vyavahare <
>> amol.vyavah...@enterprisedb.com> wrote:
>>
>>> Hi Hackers,
>>> Attached is the patch to fix the Issue with temporary tables on commit
>>> drop as. This patch fixes the issue where an error was thrown when the user
>>> tried to create a temporary table via query tool and no result
>>> was displayed when the query was executed.
>>>
>>> Please review.
>>>
>>> Please write the API test cases for the same even if the changes are
> very small but they are in the SQL Editor backend code.
> The patch is working fine and looks good to me.
>
> Thanks,
> Khushboo
>
>> --
>>> *Regards,*
>>> *Amol Vyavahare*
>>> *E**nterpriseDB Corporation*
>>> The Enterprise Postgres Company
>>> *T: +91 20 6644 9600, M: +91 738 738 2128*
>>> [image: EDB Postgres] Unit 301 A, Third
>>> Floor, Godrej Castlemaine,
>>> 155, Sassoon Road, Pune, MH - 411001
>>> [image: Blog Feed]  [image: Facebook]
>>>  [image: Twitter]
>>>  [image: LinkedIn]
>>>  [image: Google+]
>>> 
>>> Website: www.enterprisedb.com
>>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>>
>>>
>>>
>>>

-- 
*Regards,*
*Amol Vyavahare*
*E**nterpriseDB Corporation*
The Enterprise Postgres Company
*T: +91 20 6644 9600, M: +91 738 738 2128*
[image: EDB Postgres] Unit 301 A, Third Floor,
Godrej Castlemaine,
155, Sassoon Road, Pune, MH - 411001
[image: Blog Feed]  [image: Facebook]
 [image: Twitter]
 [image: LinkedIn]
 [image: Google+]

Website: www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

Re: [pgAdmin][RM5210] pgAdmin4 silently truncates text larger than underlying field size

[navnath gadakh]

Hello Hackers,


On Tue, Apr 14, 2020 at 5:14 PM Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

> Hi Navnath,
>
> You have compared the column's internal size with the length of the value
> given by the user.
> For example, column having integer would have internal size 4 and if I
> give the value 12121 which is the correct input for the field will fail
> here because as per your logic column internal size (4) < len(value) (5).
>
> I think this implementation is not correct here.
>
Yes, my implementations might be wrong.

Below are some important findings on the parameterised query(as we are
using Jinja templates for building SQL queries).
Here I have created a table 'account' with some records in it.
CREATE TABLE public.account
(
user_id integer NOT NULL,
username character varying(5)
)

psycopg2 throws a proper error if I pass username value greater than the
length of the data type(5)
Now, I want to pass username value greater than data type length (5)

Scenario 1:  Query with data type and length

import psycopg2
try:
conn = psycopg2.connect("dbname='postgres' user='postgres'
host='XXX.XXX.XXX.XXX' password='test' port=5432")
cur = conn.cursor()
cur.execute("UPDATE public.account SET username =
%(username)s::character varying(5) WHERE user_id = 1;", {"username":
"username-test-123"})
cur.execute("COMMIT;")
except Exception as e:
print('Exception : {0}'.format(e))

*Output:*

It will save the record with 5 char data without any error.

*psql output:*

postgres=# select * from public.account;
 user_id | username
-+--
   1 | usern
(1 row)

Scenario 2:  Query with only data type

import psycopg2
try:
conn = psycopg2.connect("dbname='postgres' user='postgres'
host='XXX.XXX.XXX.XXX' password='test' port=5432")
cur = conn.cursor()
cur.execute("UPDATE public.account SET username =
%(username)s::character varying WHERE user_id = 1;", {"username":
"username-test-123"})
cur.execute("COMMIT;")
except Exception as e:
print('Exception : {0}'.format(e))

*Output:*

Exception : value too long for type character varying(5)

data will not save in the table.

Scenario 3:  Query without data type

import psycopg2
try:
conn = psycopg2.connect("dbname='postgres' user='postgres'
host='XXX.XXX.XXX.XXX' password='test' port=5432")
cur = conn.cursor()
cur.execute("UPDATE public.account SET username = %(username)s
WHERE user_id = 1;", {"username": "username-test-123"})
cur.execute("COMMIT;")
except Exception as e:
print('Exception : {0}'.format(e))

*Output:*

Exception : value too long for type character varying(5)

again data will not save in the table.

These are some different behaviours with psycopg2. So to complete this
patch which apporach should I follow? or any new approach is also
welcome.

Thanks!



>
> Thanks,
> Khushboo
>
>
>
> On Tue, Apr 14, 2020 at 4:33 PM navnath gadakh <
> navnath.gad...@enterprisedb.com> wrote:
>
>> Hello Hackers,
>> Please find the attached patch for below fixes:
>>
>> - Added validation for table row data that should not be larger than the
>> field size.
>> - Rearrange the existing functions to add validation.
>> - Added test cases.
>>
>> Regards,
>> Navnath Gadakh
>>
>>

-- 
Regards,
Navnath Gadakh

Re: pgAdmin 4 - next gettext usage fixes

[Aditya Toshniwal]

Hi,

Please find the updated patch.

On Wed, Apr 15, 2020 at 1:33 PM Akshay Joshi 
wrote:

> Hi Aditya
>
> I think the fix is incorrect. .format method should be applied after
> gettext() like gettext().format(). Please check for other places too and
> send the updated patch.
>
> On Wed, Apr 15, 2020 at 11:38 AM Aditya Toshniwal <
> aditya.toshni...@enterprisedb.com> wrote:
>
>> Hi Hackers/Libor,
>>
>> The changes like below are incorrect. Try "Count rows" from a table's
>> context menu.
>>
>> -info=gettext("Table rows counted: %s" % count),
>>
>> +info=gettext("Table rows counted: %s") % count,
>>
>> Attached is the patch to fix all such changes in pgAdmin, to use format()
>> instead.
>> Please review.
>>
>> On Fri, Apr 10, 2020 at 2:57 PM Akshay Joshi <
>> akshay.jo...@enterprisedb.com> wrote:
>>
>>> Hi Libor
>>>
>>> Thanks, patch applied. Please make sure to run the PEP8 checks before
>>> sending the patch.
>>> I have fixed and committed the code.
>>>
>>> On Wed, Apr 8, 2020 at 9:30 PM Libor M.  wrote:
>>>
 Hello,
 I fixed next gettext usage:

 - fixed gettext usage with .format() only for original text with %s
 - fixed typos
 - fixed translation yes/no buttons in dialog
 - improved translating sentences without "connecting" words (eg. see
 web/pgadmin/dashboard/static/js/dashboard.js, word 'cancel' needs to
 be translated in Czech language as 'zrušit' but in another sentence as
 'zrušení')
 - added gettext for text translations

 Diff file is attached.

 Best regards,

 Libor M.

 E-mail: libor...@gmail.com
 GitHub: https://github.com/liborm85

>>>
>>>
>>> --
>>> *Thanks & Regards*
>>> *Akshay Joshi*
>>>
>>> *Sr. Software Architect*
>>> *EnterpriseDB Software India Private Limited*
>>> *Mobile: +91 976-788-8246*
>>>
>>
>>
>> --
>> Thanks and Regards,
>> Aditya Toshniwal
>> pgAdmin Hacker | Sr. Software Engineer | EnterpriseDB India | Pune
>> "Don't Complain about Heat, Plant a TREE"
>>
>
>
> --
> *Thanks & Regards*
> *Akshay Joshi*
>
> *Sr. Software Architect*
> *EnterpriseDB Software India Private Limited*
> *Mobile: +91 976-788-8246*
>


-- 
Thanks and Regards,
Aditya Toshniwal
pgAdmin Hacker | Sr. Software Engineer | EnterpriseDB India | Pune
"Don't Complain about Heat, Plant a TREE"


gettext_format_fixes_v2.patch
Description: Binary data

Re: [pgAdmin][RM5210] pgAdmin4 silently truncates text larger than underlying field size

[Khushboo Vashi]

On Wed, Apr 15, 2020 at 2:48 PM navnath gadakh <
navnath.gad...@enterprisedb.com> wrote:

> Hello Hackers,
>
>
> On Tue, Apr 14, 2020 at 5:14 PM Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>> Hi Navnath,
>>
>> You have compared the column's internal size with the length of the value
>> given by the user.
>> For example, column having integer would have internal size 4 and if I
>> give the value 12121 which is the correct input for the field will fail
>> here because as per your logic column internal size (4) < len(value) (5).
>>
>> I think this implementation is not correct here.
>>
> Yes, my implementations might be wrong.
>
> Below are some important findings on the parameterised query(as we are
> using Jinja templates for building SQL queries).
> Here I have created a table 'account' with some records in it.
> CREATE TABLE public.account
> (
> user_id integer NOT NULL,
> username character varying(5)
> )
>
> psycopg2 throws a proper error if I pass username value greater than the
> length of the data type(5)
> Now, I want to pass username value greater than data type length (5)
>
> Scenario 1:  Query with data type and length
>
> import psycopg2
> try:
> conn = psycopg2.connect("dbname='postgres' user='postgres' 
> host='XXX.XXX.XXX.XXX' password='test' port=5432")
> cur = conn.cursor()
> cur.execute("UPDATE public.account SET username = %(username)s::character 
> varying(5) WHERE user_id = 1;", {"username": "username-test-123"})
> cur.execute("COMMIT;")
> except Exception as e:
> print('Exception : {0}'.format(e))
>
> *Output:*
>
> It will save the record with 5 char data without any error.
>
> *psql output:*
>
> postgres=# select * from public.account;
>  user_id | username
> -+--
>1 | usern
> (1 row)
>
> Scenario 2:  Query with only data type
>
> import psycopg2
> try:
> conn = psycopg2.connect("dbname='postgres' user='postgres' 
> host='XXX.XXX.XXX.XXX' password='test' port=5432")
> cur = conn.cursor()
> cur.execute("UPDATE public.account SET username = %(username)s::character 
> varying WHERE user_id = 1;", {"username": "username-test-123"})
> cur.execute("COMMIT;")
> except Exception as e:
> print('Exception : {0}'.format(e))
>
> *Output:*
>
> Exception : value too long for type character varying(5)
>
> data will not save in the table.
>
> We can consider scenario 2  as it will throw the valid exception and also
typecast the value in the proper format.

> Scenario 3:  Query without data type
>
> import psycopg2
> try:
> conn = psycopg2.connect("dbname='postgres' user='postgres' 
> host='XXX.XXX.XXX.XXX' password='test' port=5432")
> cur = conn.cursor()
> cur.execute("UPDATE public.account SET username = %(username)s WHERE 
> user_id = 1;", {"username": "username-test-123"})
> cur.execute("COMMIT;")
> except Exception as e:
> print('Exception : {0}'.format(e))
>
> *Output:*
>
> Exception : value too long for type character varying(5)
>
> again data will not save in the table.
>
> These are some different behaviours with psycopg2. So to complete this patch 
> which apporach should I follow? or any new approach is also welcome.
>
> Thanks!
>
>
>
>>
>> Thanks,
>> Khushboo
>>
>>
>>
>> On Tue, Apr 14, 2020 at 4:33 PM navnath gadakh <
>> navnath.gad...@enterprisedb.com> wrote:
>>
>>> Hello Hackers,
>>> Please find the attached patch for below fixes:
>>>
>>> - Added validation for table row data that should not be larger than the
>>> field size.
>>> - Rearrange the existing functions to add validation.
>>> - Added test cases.
>>>
>>> Regards,
>>> Navnath Gadakh
>>>
>>>
>
> --
> Regards,
> Navnath Gadakh
>

Re: [pgAdmin][RM5210] pgAdmin4 silently truncates text larger than underlying field size

[Aditya Toshniwal]

Hi,

I think this is not a bug. From what I can see, the query - "UPDATE
public.account SET username = 'username-test-123'::character varying(5)
WHERE user_id = 1;" will not throw any error from psql. The same query is
fired by pgAdmin, hence no error.

To get an error we need to remove the typecasting in update. I think we
should close the bug with no change.


On Wed, Apr 15, 2020 at 2:48 PM navnath gadakh <
navnath.gad...@enterprisedb.com> wrote:

> Hello Hackers,
>
>
> On Tue, Apr 14, 2020 at 5:14 PM Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>> Hi Navnath,
>>
>> You have compared the column's internal size with the length of the value
>> given by the user.
>> For example, column having integer would have internal size 4 and if I
>> give the value 12121 which is the correct input for the field will fail
>> here because as per your logic column internal size (4) < len(value) (5).
>>
>> I think this implementation is not correct here.
>>
> Yes, my implementations might be wrong.
>
> Below are some important findings on the parameterised query(as we are
> using Jinja templates for building SQL queries).
> Here I have created a table 'account' with some records in it.
> CREATE TABLE public.account
> (
> user_id integer NOT NULL,
> username character varying(5)
> )
>
> psycopg2 throws a proper error if I pass username value greater than the
> length of the data type(5)
> Now, I want to pass username value greater than data type length (5)
>
> Scenario 1:  Query with data type and length
>
> import psycopg2
> try:
> conn = psycopg2.connect("dbname='postgres' user='postgres' 
> host='XXX.XXX.XXX.XXX' password='test' port=5432")
> cur = conn.cursor()
> cur.execute("UPDATE public.account SET username = %(username)s::character 
> varying(5) WHERE user_id = 1;", {"username": "username-test-123"})
> cur.execute("COMMIT;")
> except Exception as e:
> print('Exception : {0}'.format(e))
>
> *Output:*
>
> It will save the record with 5 char data without any error.
>
> *psql output:*
>
> postgres=# select * from public.account;
>  user_id | username
> -+--
>1 | usern
> (1 row)
>
> Scenario 2:  Query with only data type
>
> import psycopg2
> try:
> conn = psycopg2.connect("dbname='postgres' user='postgres' 
> host='XXX.XXX.XXX.XXX' password='test' port=5432")
> cur = conn.cursor()
> cur.execute("UPDATE public.account SET username = %(username)s::character 
> varying WHERE user_id = 1;", {"username": "username-test-123"})
> cur.execute("COMMIT;")
> except Exception as e:
> print('Exception : {0}'.format(e))
>
> *Output:*
>
> Exception : value too long for type character varying(5)
>
> data will not save in the table.
>
> Scenario 3:  Query without data type
>
> import psycopg2
> try:
> conn = psycopg2.connect("dbname='postgres' user='postgres' 
> host='XXX.XXX.XXX.XXX' password='test' port=5432")
> cur = conn.cursor()
> cur.execute("UPDATE public.account SET username = %(username)s WHERE 
> user_id = 1;", {"username": "username-test-123"})
> cur.execute("COMMIT;")
> except Exception as e:
> print('Exception : {0}'.format(e))
>
> *Output:*
>
> Exception : value too long for type character varying(5)
>
> again data will not save in the table.
>
> These are some different behaviours with psycopg2. So to complete this patch 
> which apporach should I follow? or any new approach is also welcome.
>
> Thanks!
>
>
>
>>
>> Thanks,
>> Khushboo
>>
>>
>>
>> On Tue, Apr 14, 2020 at 4:33 PM navnath gadakh <
>> navnath.gad...@enterprisedb.com> wrote:
>>
>>> Hello Hackers,
>>> Please find the attached patch for below fixes:
>>>
>>> - Added validation for table row data that should not be larger than the
>>> field size.
>>> - Rearrange the existing functions to add validation.
>>> - Added test cases.
>>>
>>> Regards,
>>> Navnath Gadakh
>>>
>>>
>
> --
> Regards,
> Navnath Gadakh
>


-- 
Thanks and Regards,
Aditya Toshniwal
pgAdmin Hacker | Sr. Software Engineer | EnterpriseDB India | Pune
"Don't Complain about Heat, Plant a TREE"

Re: [pgAdmin][RM5210] pgAdmin4 silently truncates text larger than underlying field size

[Neel Patel]

Hi,

I think we should remove the type cast from query during update and
whatever error is thrown should be shown to UI as per scenario 3.

Thanks,
Neel Patel

On Wed, Apr 15, 2020 at 3:06 PM Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

>
>
> On Wed, Apr 15, 2020 at 2:48 PM navnath gadakh <
> navnath.gad...@enterprisedb.com> wrote:
>
>> Hello Hackers,
>>
>>
>> On Tue, Apr 14, 2020 at 5:14 PM Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>> Hi Navnath,
>>>
>>> You have compared the column's internal size with the length of the
>>> value given by the user.
>>> For example, column having integer would have internal size 4 and if I
>>> give the value 12121 which is the correct input for the field will fail
>>> here because as per your logic column internal size (4) < len(value) (5).
>>>
>>> I think this implementation is not correct here.
>>>
>> Yes, my implementations might be wrong.
>>
>> Below are some important findings on the parameterised query(as we are
>> using Jinja templates for building SQL queries).
>> Here I have created a table 'account' with some records in it.
>> CREATE TABLE public.account
>> (
>> user_id integer NOT NULL,
>> username character varying(5)
>> )
>>
>> psycopg2 throws a proper error if I pass username value greater than the
>> length of the data type(5)
>> Now, I want to pass username value greater than data type length (5)
>>
>> Scenario 1:  Query with data type and length
>>
>> import psycopg2
>> try:
>> conn = psycopg2.connect("dbname='postgres' user='postgres' 
>> host='XXX.XXX.XXX.XXX' password='test' port=5432")
>> cur = conn.cursor()
>> cur.execute("UPDATE public.account SET username = 
>> %(username)s::character varying(5) WHERE user_id = 1;", {"username": 
>> "username-test-123"})
>> cur.execute("COMMIT;")
>> except Exception as e:
>> print('Exception : {0}'.format(e))
>>
>> *Output:*
>>
>> It will save the record with 5 char data without any error.
>>
>> *psql output:*
>>
>> postgres=# select * from public.account;
>>  user_id | username
>> -+--
>>1 | usern
>> (1 row)
>>
>> Scenario 2:  Query with only data type
>>
>> import psycopg2
>> try:
>> conn = psycopg2.connect("dbname='postgres' user='postgres' 
>> host='XXX.XXX.XXX.XXX' password='test' port=5432")
>> cur = conn.cursor()
>> cur.execute("UPDATE public.account SET username = 
>> %(username)s::character varying WHERE user_id = 1;", {"username": 
>> "username-test-123"})
>> cur.execute("COMMIT;")
>> except Exception as e:
>> print('Exception : {0}'.format(e))
>>
>> *Output:*
>>
>> Exception : value too long for type character varying(5)
>>
>> data will not save in the table.
>>
>> We can consider scenario 2  as it will throw the valid exception and also
> typecast the value in the proper format.
>
>> Scenario 3:  Query without data type
>>
>> import psycopg2
>> try:
>> conn = psycopg2.connect("dbname='postgres' user='postgres' 
>> host='XXX.XXX.XXX.XXX' password='test' port=5432")
>> cur = conn.cursor()
>> cur.execute("UPDATE public.account SET username = %(username)s WHERE 
>> user_id = 1;", {"username": "username-test-123"})
>> cur.execute("COMMIT;")
>> except Exception as e:
>> print('Exception : {0}'.format(e))
>>
>> *Output:*
>>
>> Exception : value too long for type character varying(5)
>>
>> again data will not save in the table.
>>
>> These are some different behaviours with psycopg2. So to complete this patch 
>> which apporach should I follow? or any new approach is also welcome.
>>
>> Thanks!
>>
>>
>>
>>>
>>> Thanks,
>>> Khushboo
>>>
>>>
>>>
>>> On Tue, Apr 14, 2020 at 4:33 PM navnath gadakh <
>>> navnath.gad...@enterprisedb.com> wrote:
>>>
 Hello Hackers,
 Please find the attached patch for below fixes:

 - Added validation for table row data that should not be larger
 than the field size.
 - Rearrange the existing functions to add validation.
 - Added test cases.

 Regards,
 Navnath Gadakh


>>
>> --
>> Regards,
>> Navnath Gadakh
>>
>

Re: [pgAdmin4][Patch] - RM 4957 - Constraint Trigger, Deferrable, Deferred option should be disbled if user select EDB-SPL function for trigger for EPAS.

[Akshay Joshi]

Hi Khushboo

The fix is not correct, as per RM, we should disable Constraint Trigger,
Deferrable, Deferred option when the user selects the "Inline EDB-SPL"
function.
With this patch, it is disabled for EPAS. Please fix and resend the patch.

On Wed, Apr 15, 2020 at 12:06 PM Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

> Hi,
>
> Please find the attached small patch to fix the issue #4957 - Constraint
> Trigger, Deferrable, Deferred option should be disbled if user select
> EDB-SPL function for trigger for EPAS.
>
> Thanks,
> Khushboo
>
>

-- 
*Thanks & Regards*
*Akshay Joshi*

*Sr. Software Architect*
*EnterpriseDB Software India Private Limited*
*Mobile: +91 976-788-8246*

[pgAdmin4 Patch - RM 4440]

[Shubham Agarwal]

Hi Team,
PFA patch containing the fix and the resql test cases.

-- 
Thanks & Regards,
Shubham Agarwal
EnterpriseDB Corporation

The Postgres Database Company

Re: [pgAdmin4 Patch - RM 4440]

[Khushboo Vashi]

On Wed, Apr 15, 2020 at 4:29 PM Shubham Agarwal <
shubham.agar...@enterprisedb.com> wrote:

> Hi Team,
> PFA patch containing the fix and the resql test cases.
>
> You forgot to attach the patch.

> --
> Thanks & Regards,
> Shubham Agarwal
> EnterpriseDB Corporation
>
> The Postgres Database Company
>

Re: [pgAdmin4 Patch - RM 4440]

[Shubham Agarwal]

On Wed, Apr 15, 2020 at 4:31 PM Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

>
>
> On Wed, Apr 15, 2020 at 4:29 PM Shubham Agarwal <
> shubham.agar...@enterprisedb.com> wrote:
>
>> Hi Team,
>> PFA patch containing the fix and the resql test cases.
>>
>> You forgot to attach the patch.
>
>> --
>> Thanks & Regards,
>> Shubham Agarwal
>> EnterpriseDB Corporation
>>
>> The Postgres Database Company
>>
>

-- 
Thanks & Regards,
Shubham Agarwal
EnterpriseDB Corporation

The Postgres Database Company


rm_4440_v1.patch
Description: Binary data

pgAdmin 4 commit: Make changes to use gettext() function correctly.

[Akshay Joshi]

Make changes to use gettext() function correctly.

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=31a929388b3adb153a3b09be284dce3869bb39fe
Author: Aditya Toshniwal 

Modified Files
--
web/pgadmin/__init__.py| 10 --
web/pgadmin/browser/server_groups/servers/__init__.py  |  8 +---
.../browser/server_groups/servers/databases/__init__.py|  3 ++-
.../browser/server_groups/servers/databases/casts/__init__.py  |  3 ++-
.../server_groups/servers/databases/event_triggers/__init__.py |  5 +++--
.../server_groups/servers/databases/extensions/__init__.py |  3 ++-
.../servers/databases/external_tables/properties.py|  6 +++---
.../servers/databases/foreign_data_wrappers/__init__.py|  3 ++-
.../foreign_data_wrappers/foreign_servers/__init__.py  |  3 ++-
.../foreign_servers/user_mappings/__init__.py  |  3 ++-
.../server_groups/servers/databases/languages/__init__.py  |  3 ++-
.../server_groups/servers/databases/schemas/__init__.py|  4 ++--
.../servers/databases/schemas/collations/__init__.py   |  3 ++-
.../servers/databases/schemas/fts_configurations/__init__.py   |  3 ++-
.../servers/databases/schemas/fts_parsers/__init__.py  |  3 ++-
.../servers/databases/schemas/fts_templates/__init__.py|  3 ++-
.../servers/databases/schemas/packages/__init__.py |  3 ++-
.../servers/databases/schemas/synonyms/__init__.py |  3 ++-
.../server_groups/servers/databases/schemas/tables/__init__.py |  5 +++--
.../servers/databases/schemas/tables/columns/__init__.py   |  4 ++--
.../databases/schemas/tables/compound_triggers/__init__.py |  4 ++--
.../schemas/tables/constraints/check_constraint/__init__.py|  3 ++-
.../tables/constraints/exclusion_constraint/__init__.py|  6 --
.../schemas/tables/constraints/foreign_key/__init__.py |  6 --
.../schemas/tables/constraints/index_constraint/__init__.py|  5 +++--
.../servers/databases/schemas/tables/indexes/__init__.py   |  4 ++--
.../server_groups/servers/databases/schemas/types/__init__.py  |  4 ++--
.../server_groups/servers/databases/schemas/views/__init__.py  |  5 +++--
web/pgadmin/browser/server_groups/servers/pgagent/__init__.py  |  3 ++-
.../browser/server_groups/servers/resource_groups/__init__.py  |  3 ++-
.../browser/server_groups/servers/tablespaces/__init__.py  |  4 ++--
31 files changed, 76 insertions(+), 52 deletions(-)

pgAdmin 4 commit: Added alert message to Reset Layout if any of the pan

[Akshay Joshi]

Added alert message to Reset Layout if any of the panels from Query Tool failed 
to load. Fixes #5366

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=ed0a596286a7f0fef741f91633e76b39e1ca338f
Author: Khushboo Vashi 

Modified Files
--
docs/en_US/release_notes_4_21.rst   |  1 +
web/pgadmin/static/js/sqleditor/query_tool_notifications.js |  2 +-
web/pgadmin/tools/sqleditor/static/js/sqleditor.js  | 10 ++
3 files changed, 12 insertions(+), 1 deletion(-)

pgAdmin 4 commit: Fixed python exception error when user tries to downl

[Akshay Joshi]

Fixed python exception error when user tries to download the CSV and there is a 
connection issue. Fixes #4858

Branch
--
master

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

Modified Files
--
docs/en_US/release_notes_4_21.rst  |  1 +
.../js/sqleditor/query_tool_http_error_handler.js  |  2 +
web/pgadmin/tools/sqleditor/__init__.py|  6 +-
web/pgadmin/tools/sqleditor/static/js/sqleditor.js | 64 ++
4 files changed, 49 insertions(+), 24 deletions(-)

Re: [pgAdmin4][RM#4858] Allow user to reconnect to DB server when connection is drop

[Akshay Joshi]

Thanks, patch applied.

On Wed, Apr 15, 2020 at 12:22 PM Murtuza Zabuawala <
murtuza.zabuaw...@enterprisedb.com> wrote:

> Hi Akshay,
>
> PFA updated patch.
>
>
> --
> Regards,
> Murtuza Zabuawala
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
>
> On Mon, Apr 13, 2020 at 2:28 PM Akshay Joshi <
> akshay.jo...@enterprisedb.com> wrote:
>
>> Hi Murtuza
>>
>> The issue has been fixed with your patch, but there is an existing issue
>> discover with the fix.
>> After disconnecting the server and click on Download CSV button
>> confirmation dialog comes and user needs to click twice.
>> Following error observed in the browser:
>>
>> sqleditor.js?ver=42000:1 Uncaught TypeError: Cannot read property 'apply'
>> of undefined
>> at Object. (sqleditor.js?ver=42000:1)
>> at Object.callback (vendor.others.js?ver=42000:2)
>> at Tt (vendor.others.js?ver=42000:2)
>> at Object.Ct (vendor.others.js?ver=42000:2)
>> at HTMLDivElement. (vendor.others.js?ver=42000:2)
>>
>> If possible can you please fix the above and resend the combined patch.
>>
>> On Fri, Apr 10, 2020 at 7:02 PM Murtuza Zabuawala <
>> murtuza.zabuaw...@enterprisedb.com> wrote:
>>
>>> Hi,
>>>
>>> Upon downloading the csv file, we used the prompt for re-connecting to
>>> the database server when there is a database server connection issue.
>>> Currently the user tries to download CSV and there is a connection issue
>>> then it is showing a python exception error.
>>>
>>> Steps:
>>> 1) Open query tool
>>> 2) Execute -> SELECT 1,2,3
>>> 3) Disconnect from server from browser tree
>>> 4) Click on Download CSV button
>>>
>>> Current: Python exception error
>>> Expected: It should display dialog to reconnect the server.
>>>
>>>
>>> --
>>> Regards,
>>> Murtuza Zabuawala
>>> EnterpriseDB: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>>
>>>
>>
>> --
>> *Thanks & Regards*
>> *Akshay Joshi*
>>
>> *Sr. Software Architect*
>> *EnterpriseDB Software India Private Limited*
>> *Mobile: +91 976-788-8246*
>>
>

-- 
*Thanks & Regards*
*Akshay Joshi*

*Sr. Software Architect*
*EnterpriseDB Software India Private Limited*
*Mobile: +91 976-788-8246*

Re: pgAdmin 4 - next gettext usage fixes

[Akshay Joshi]

Thanks, patch applied.

On Wed, Apr 15, 2020 at 2:55 PM Aditya Toshniwal <
aditya.toshni...@enterprisedb.com> wrote:

> Hi,
>
> Please find the updated patch.
>
> On Wed, Apr 15, 2020 at 1:33 PM Akshay Joshi <
> akshay.jo...@enterprisedb.com> wrote:
>
>> Hi Aditya
>>
>> I think the fix is incorrect. .format method should be applied after
>> gettext() like gettext().format(). Please check for other places too and
>> send the updated patch.
>>
>> On Wed, Apr 15, 2020 at 11:38 AM Aditya Toshniwal <
>> aditya.toshni...@enterprisedb.com> wrote:
>>
>>> Hi Hackers/Libor,
>>>
>>> The changes like below are incorrect. Try "Count rows" from a table's
>>> context menu.
>>>
>>> -info=gettext("Table rows counted: %s" % count),
>>>
>>> +info=gettext("Table rows counted: %s") % count,
>>>
>>> Attached is the patch to fix all such changes in pgAdmin, to use
>>> format() instead.
>>> Please review.
>>>
>>> On Fri, Apr 10, 2020 at 2:57 PM Akshay Joshi <
>>> akshay.jo...@enterprisedb.com> wrote:
>>>
 Hi Libor

 Thanks, patch applied. Please make sure to run the PEP8 checks before
 sending the patch.
 I have fixed and committed the code.

 On Wed, Apr 8, 2020 at 9:30 PM Libor M.  wrote:

> Hello,
> I fixed next gettext usage:
>
> - fixed gettext usage with .format() only for original text with %s
> - fixed typos
> - fixed translation yes/no buttons in dialog
> - improved translating sentences without "connecting" words (eg. see
> web/pgadmin/dashboard/static/js/dashboard.js, word 'cancel' needs to
> be translated in Czech language as 'zrušit' but in another sentence as
> 'zrušení')
> - added gettext for text translations
>
> Diff file is attached.
>
> Best regards,
>
> Libor M.
>
> E-mail: libor...@gmail.com
> GitHub: https://github.com/liborm85
>


 --
 *Thanks & Regards*
 *Akshay Joshi*

 *Sr. Software Architect*
 *EnterpriseDB Software India Private Limited*
 *Mobile: +91 976-788-8246*

>>>
>>>
>>> --
>>> Thanks and Regards,
>>> Aditya Toshniwal
>>> pgAdmin Hacker | Sr. Software Engineer | EnterpriseDB India | Pune
>>> "Don't Complain about Heat, Plant a TREE"
>>>
>>
>>
>> --
>> *Thanks & Regards*
>> *Akshay Joshi*
>>
>> *Sr. Software Architect*
>> *EnterpriseDB Software India Private Limited*
>> *Mobile: +91 976-788-8246*
>>
>
>
> --
> Thanks and Regards,
> Aditya Toshniwal
> pgAdmin Hacker | Sr. Software Engineer | EnterpriseDB India | Pune
> "Don't Complain about Heat, Plant a TREE"
>


-- 
*Thanks & Regards*
*Akshay Joshi*

*Sr. Software Architect*
*EnterpriseDB Software India Private Limited*
*Mobile: +91 976-788-8246*

Re: [pgAdmin4][Patch]: RM 5366 - PgAdmin hangs in 'loading' state after trying to preview the first 100 records

[Akshay Joshi]

Thanks, patch applied.

On Wed, Apr 15, 2020 at 10:32 AM Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

> Hi,
>
> Please find the attached patch to fix the RM #5366 - PgAdmin hangs in '
> loading' state after trying to preview the first 100 records.
>
> Many users reported this issue but the root cause of the issue has not
> been found yet and with the Reset Layout option, this issue is getting
> fixed.
>
> So, in order to fix the issue, I have added the alert to reset the layout
> if any of the panels from Sql Editor fails to load.
>
> Thanks,
> Khushboo
>


-- 
*Thanks & Regards*
*Akshay Joshi*

*Sr. Software Architect*
*EnterpriseDB Software India Private Limited*
*Mobile: +91 976-788-8246*

Re: [pgAdmin4][Patch] - RM 4957 - Constraint Trigger, Deferrable, Deferred option should be disbled if user select EDB-SPL function for trigger for EPAS.

[Khushboo Vashi]

Hi Akshay,

Please find the attached updated patch.

Thanks,
Khushboo

On Wed, Apr 15, 2020 at 3:58 PM Akshay Joshi 
wrote:

> Hi Khushboo
>
> The fix is not correct, as per RM, we should disable Constraint Trigger,
> Deferrable, Deferred option when the user selects the "Inline EDB-SPL"
> function.
> With this patch, it is disabled for EPAS. Please fix and resend the patch.
>
> On Wed, Apr 15, 2020 at 12:06 PM Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>> Hi,
>>
>> Please find the attached small patch to fix the issue #4957 - Constraint
>> Trigger, Deferrable, Deferred option should be disbled if user select
>> EDB-SPL function for trigger for EPAS.
>>
>> Thanks,
>> Khushboo
>>
>>
>
> --
> *Thanks & Regards*
> *Akshay Joshi*
>
> *Sr. Software Architect*
> *EnterpriseDB Software India Private Limited*
> *Mobile: +91 976-788-8246*
>


RM_4957_v1.patch
Description: Binary data

Re: pgAdmin 4 - next gettext usage fixes

[Libor M.]

Hi,
next minor gettext and format fixes in patch.

Best regards,

Libor M.

E-mail: libor...@gmail.com
GitHub: https://github.com/liborm85

st 15. 4. 2020 v 13:17 odesílatel Akshay Joshi
 napsal:
>
> Thanks, patch applied.
>
> On Wed, Apr 15, 2020 at 2:55 PM Aditya Toshniwal 
>  wrote:
>>
>> Hi,
>>
>> Please find the updated patch.
>>
>> On Wed, Apr 15, 2020 at 1:33 PM Akshay Joshi  
>> wrote:
>>>
>>> Hi Aditya
>>>
>>> I think the fix is incorrect. .format method should be applied after 
>>> gettext() like gettext().format(). Please check for other places too and 
>>> send the updated patch.
>>>
>>> On Wed, Apr 15, 2020 at 11:38 AM Aditya Toshniwal 
>>>  wrote:

 Hi Hackers/Libor,

 The changes like below are incorrect. Try "Count rows" from a table's 
 context menu.

 -info=gettext("Table rows counted: %s" % count),

 +info=gettext("Table rows counted: %s") % count,


 Attached is the patch to fix all such changes in pgAdmin, to use format() 
 instead.
 Please review.

 On Fri, Apr 10, 2020 at 2:57 PM Akshay Joshi 
  wrote:
>
> Hi Libor
>
> Thanks, patch applied. Please make sure to run the PEP8 checks before 
> sending the patch.
> I have fixed and committed the code.
>
> On Wed, Apr 8, 2020 at 9:30 PM Libor M.  wrote:
>>
>> Hello,
>> I fixed next gettext usage:
>>
>> - fixed gettext usage with .format() only for original text with %s
>> - fixed typos
>> - fixed translation yes/no buttons in dialog
>> - improved translating sentences without "connecting" words (eg. see
>> web/pgadmin/dashboard/static/js/dashboard.js, word 'cancel' needs to
>> be translated in Czech language as 'zrušit' but in another sentence as
>> 'zrušení')
>> - added gettext for text translations
>>
>> Diff file is attached.
>>
>> Best regards,
>>
>> Libor M.
>>
>> E-mail: libor...@gmail.com
>> GitHub: https://github.com/liborm85
>
>
>
> --
> Thanks & Regards
> Akshay Joshi
> Sr. Software Architect
> EnterpriseDB Software India Private Limited
> Mobile: +91 976-788-8246



 --
 Thanks and Regards,
 Aditya Toshniwal
 pgAdmin Hacker | Sr. Software Engineer | EnterpriseDB India | Pune
 "Don't Complain about Heat, Plant a TREE"
>>>
>>>
>>>
>>> --
>>> Thanks & Regards
>>> Akshay Joshi
>>> Sr. Software Architect
>>> EnterpriseDB Software India Private Limited
>>> Mobile: +91 976-788-8246
>>
>>
>>
>> --
>> Thanks and Regards,
>> Aditya Toshniwal
>> pgAdmin Hacker | Sr. Software Engineer | EnterpriseDB India | Pune
>> "Don't Complain about Heat, Plant a TREE"
>
>
>
> --
> Thanks & Regards
> Akshay Joshi
> Sr. Software Architect
> EnterpriseDB Software India Private Limited
> Mobile: +91 976-788-8246


pgadmin4_gettext.diff
Description: Binary data

Re: [pgAdmin][RM5210] pgAdmin4 silently truncates text larger than underlying field size

[navnath gadakh]

@Dave Page   @Akshay Joshi
 your input please?

On Wed, Apr 15, 2020 at 3:13 PM Neel Patel 
wrote:

> Hi,
>
> I think we should remove the type cast from query during update and
> whatever error is thrown should be shown to UI as per scenario 3.
>
> Thanks,
> Neel Patel
>
> On Wed, Apr 15, 2020 at 3:06 PM Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>>
>>
>> On Wed, Apr 15, 2020 at 2:48 PM navnath gadakh <
>> navnath.gad...@enterprisedb.com> wrote:
>>
>>> Hello Hackers,
>>>
>>>
>>> On Tue, Apr 14, 2020 at 5:14 PM Khushboo Vashi <
>>> khushboo.va...@enterprisedb.com> wrote:
>>>
 Hi Navnath,

 You have compared the column's internal size with the length of the
 value given by the user.
 For example, column having integer would have internal size 4 and if I
 give the value 12121 which is the correct input for the field will fail
 here because as per your logic column internal size (4) < len(value) (5).

 I think this implementation is not correct here.

>>> Yes, my implementations might be wrong.
>>>
>>> Below are some important findings on the parameterised query(as we are
>>> using Jinja templates for building SQL queries).
>>> Here I have created a table 'account' with some records in it.
>>> CREATE TABLE public.account
>>> (
>>> user_id integer NOT NULL,
>>> username character varying(5)
>>> )
>>>
>>> psycopg2 throws a proper error if I pass username value greater than the
>>> length of the data type(5)
>>> Now, I want to pass username value greater than data type length (5)
>>>
>>> Scenario 1:  Query with data type and length
>>>
>>> import psycopg2
>>> try:
>>> conn = psycopg2.connect("dbname='postgres' user='postgres' 
>>> host='XXX.XXX.XXX.XXX' password='test' port=5432")
>>> cur = conn.cursor()
>>> cur.execute("UPDATE public.account SET username = 
>>> %(username)s::character varying(5) WHERE user_id = 1;", {"username": 
>>> "username-test-123"})
>>> cur.execute("COMMIT;")
>>> except Exception as e:
>>> print('Exception : {0}'.format(e))
>>>
>>> *Output:*
>>>
>>> It will save the record with 5 char data without any error.
>>>
>>> *psql output:*
>>>
>>> postgres=# select * from public.account;
>>>  user_id | username
>>> -+--
>>>1 | usern
>>> (1 row)
>>>
>>> Scenario 2:  Query with only data type
>>>
>>> import psycopg2
>>> try:
>>> conn = psycopg2.connect("dbname='postgres' user='postgres' 
>>> host='XXX.XXX.XXX.XXX' password='test' port=5432")
>>> cur = conn.cursor()
>>> cur.execute("UPDATE public.account SET username = 
>>> %(username)s::character varying WHERE user_id = 1;", {"username": 
>>> "username-test-123"})
>>> cur.execute("COMMIT;")
>>> except Exception as e:
>>> print('Exception : {0}'.format(e))
>>>
>>> *Output:*
>>>
>>> Exception : value too long for type character varying(5)
>>>
>>> data will not save in the table.
>>>
>>> We can consider scenario 2  as it will throw the valid exception and
>> also typecast the value in the proper format.
>>
>>> Scenario 3:  Query without data type
>>>
>>> import psycopg2
>>> try:
>>> conn = psycopg2.connect("dbname='postgres' user='postgres' 
>>> host='XXX.XXX.XXX.XXX' password='test' port=5432")
>>> cur = conn.cursor()
>>> cur.execute("UPDATE public.account SET username = %(username)s WHERE 
>>> user_id = 1;", {"username": "username-test-123"})
>>> cur.execute("COMMIT;")
>>> except Exception as e:
>>> print('Exception : {0}'.format(e))
>>>
>>> *Output:*
>>>
>>> Exception : value too long for type character varying(5)
>>>
>>> again data will not save in the table.
>>>
>>> These are some different behaviours with psycopg2. So to complete this 
>>> patch which apporach should I follow? or any new approach is also welcome.
>>>
>>> Thanks!
>>>
>>>
>>>

 Thanks,
 Khushboo



 On Tue, Apr 14, 2020 at 4:33 PM navnath gadakh <
 navnath.gad...@enterprisedb.com> wrote:

> Hello Hackers,
> Please find the attached patch for below fixes:
>
> - Added validation for table row data that should not be larger
> than the field size.
> - Rearrange the existing functions to add validation.
> - Added test cases.
>
> Regards,
> Navnath Gadakh
>
>
>>>
>>> --
>>> Regards,
>>> Navnath Gadakh
>>>
>>

-- 
Regards,
Navnath Gadakh

Re: [pgAdmin][RM5210] pgAdmin4 silently truncates text larger than underlying field size

[Akshay Joshi]

Hi Navnath

Scenario 3 seems correct to me. No need to type cast.

On Wed, Apr 15, 2020 at 6:03 PM navnath gadakh <
navnath.gad...@enterprisedb.com> wrote:

> @Dave Page   @Akshay Joshi
>  your input please?
>
> On Wed, Apr 15, 2020 at 3:13 PM Neel Patel 
> wrote:
>
>> Hi,
>>
>> I think we should remove the type cast from query during update and
>> whatever error is thrown should be shown to UI as per scenario 3.
>>
>> Thanks,
>> Neel Patel
>>
>> On Wed, Apr 15, 2020 at 3:06 PM Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>>
>>>
>>> On Wed, Apr 15, 2020 at 2:48 PM navnath gadakh <
>>> navnath.gad...@enterprisedb.com> wrote:
>>>
 Hello Hackers,


 On Tue, Apr 14, 2020 at 5:14 PM Khushboo Vashi <
 khushboo.va...@enterprisedb.com> wrote:

> Hi Navnath,
>
> You have compared the column's internal size with the length of the
> value given by the user.
> For example, column having integer would have internal size 4 and if I
> give the value 12121 which is the correct input for the field will fail
> here because as per your logic column internal size (4) < len(value) (5).
>
> I think this implementation is not correct here.
>
 Yes, my implementations might be wrong.

 Below are some important findings on the parameterised query(as we are
 using Jinja templates for building SQL queries).
 Here I have created a table 'account' with some records in it.
 CREATE TABLE public.account
 (
 user_id integer NOT NULL,
 username character varying(5)
 )

 psycopg2 throws a proper error if I pass username value greater than
 the length of the data type(5)
 Now, I want to pass username value greater than data type length (5)

 Scenario 1:  Query with data type and length

 import psycopg2
 try:
 conn = psycopg2.connect("dbname='postgres' user='postgres' 
 host='XXX.XXX.XXX.XXX' password='test' port=5432")
 cur = conn.cursor()
 cur.execute("UPDATE public.account SET username = 
 %(username)s::character varying(5) WHERE user_id = 1;", {"username": 
 "username-test-123"})
 cur.execute("COMMIT;")
 except Exception as e:
 print('Exception : {0}'.format(e))

 *Output:*

 It will save the record with 5 char data without any error.

 *psql output:*

 postgres=# select * from public.account;
  user_id | username
 -+--
1 | usern
 (1 row)

 Scenario 2:  Query with only data type

 import psycopg2
 try:
 conn = psycopg2.connect("dbname='postgres' user='postgres' 
 host='XXX.XXX.XXX.XXX' password='test' port=5432")
 cur = conn.cursor()
 cur.execute("UPDATE public.account SET username = 
 %(username)s::character varying WHERE user_id = 1;", {"username": 
 "username-test-123"})
 cur.execute("COMMIT;")
 except Exception as e:
 print('Exception : {0}'.format(e))

 *Output:*

 Exception : value too long for type character varying(5)

 data will not save in the table.

 We can consider scenario 2  as it will throw the valid exception and
>>> also typecast the value in the proper format.
>>>
 Scenario 3:  Query without data type

 import psycopg2
 try:
 conn = psycopg2.connect("dbname='postgres' user='postgres' 
 host='XXX.XXX.XXX.XXX' password='test' port=5432")
 cur = conn.cursor()
 cur.execute("UPDATE public.account SET username = %(username)s WHERE 
 user_id = 1;", {"username": "username-test-123"})
 cur.execute("COMMIT;")
 except Exception as e:
 print('Exception : {0}'.format(e))

 *Output:*

 Exception : value too long for type character varying(5)

 again data will not save in the table.

 These are some different behaviours with psycopg2. So to complete this 
 patch which apporach should I follow? or any new approach is also welcome.

 Thanks!



>
> Thanks,
> Khushboo
>
>
>
> On Tue, Apr 14, 2020 at 4:33 PM navnath gadakh <
> navnath.gad...@enterprisedb.com> wrote:
>
>> Hello Hackers,
>> Please find the attached patch for below fixes:
>>
>> - Added validation for table row data that should not be larger
>> than the field size.
>> - Rearrange the existing functions to add validation.
>> - Added test cases.
>>
>> Regards,
>> Navnath Gadakh
>>
>>

 --
 Regards,
 Navnath Gadakh

>>>
>
> --
> Regards,
> Navnath Gadakh
>


-- 
*Thanks & Regards*
*Akshay Joshi*

*Sr. Software Architect*
*EnterpriseDB Software India Private Limited*
*Mobile: +91 976-788-8246*

Re: [pgAdmin][RM5210] pgAdmin4 silently truncates text larger than underlying field size

[Dave Page]

Removing the typecast will almost certainly lead to other problems. I think
we should just remove the length from it.

On Wed, Apr 15, 2020 at 1:33 PM navnath gadakh <
navnath.gad...@enterprisedb.com> wrote:

> @Dave Page   @Akshay Joshi
>  your input please?
>
> On Wed, Apr 15, 2020 at 3:13 PM Neel Patel 
> wrote:
>
>> Hi,
>>
>> I think we should remove the type cast from query during update and
>> whatever error is thrown should be shown to UI as per scenario 3.
>>
>> Thanks,
>> Neel Patel
>>
>> On Wed, Apr 15, 2020 at 3:06 PM Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>>
>>>
>>> On Wed, Apr 15, 2020 at 2:48 PM navnath gadakh <
>>> navnath.gad...@enterprisedb.com> wrote:
>>>
 Hello Hackers,


 On Tue, Apr 14, 2020 at 5:14 PM Khushboo Vashi <
 khushboo.va...@enterprisedb.com> wrote:

> Hi Navnath,
>
> You have compared the column's internal size with the length of the
> value given by the user.
> For example, column having integer would have internal size 4 and if I
> give the value 12121 which is the correct input for the field will fail
> here because as per your logic column internal size (4) < len(value) (5).
>
> I think this implementation is not correct here.
>
 Yes, my implementations might be wrong.

 Below are some important findings on the parameterised query(as we are
 using Jinja templates for building SQL queries).
 Here I have created a table 'account' with some records in it.
 CREATE TABLE public.account
 (
 user_id integer NOT NULL,
 username character varying(5)
 )

 psycopg2 throws a proper error if I pass username value greater than
 the length of the data type(5)
 Now, I want to pass username value greater than data type length (5)

 Scenario 1:  Query with data type and length

 import psycopg2
 try:
 conn = psycopg2.connect("dbname='postgres' user='postgres' 
 host='XXX.XXX.XXX.XXX' password='test' port=5432")
 cur = conn.cursor()
 cur.execute("UPDATE public.account SET username = 
 %(username)s::character varying(5) WHERE user_id = 1;", {"username": 
 "username-test-123"})
 cur.execute("COMMIT;")
 except Exception as e:
 print('Exception : {0}'.format(e))

 *Output:*

 It will save the record with 5 char data without any error.

 *psql output:*

 postgres=# select * from public.account;
  user_id | username
 -+--
1 | usern
 (1 row)

 Scenario 2:  Query with only data type

 import psycopg2
 try:
 conn = psycopg2.connect("dbname='postgres' user='postgres' 
 host='XXX.XXX.XXX.XXX' password='test' port=5432")
 cur = conn.cursor()
 cur.execute("UPDATE public.account SET username = 
 %(username)s::character varying WHERE user_id = 1;", {"username": 
 "username-test-123"})
 cur.execute("COMMIT;")
 except Exception as e:
 print('Exception : {0}'.format(e))

 *Output:*

 Exception : value too long for type character varying(5)

 data will not save in the table.

 We can consider scenario 2  as it will throw the valid exception and
>>> also typecast the value in the proper format.
>>>
 Scenario 3:  Query without data type

 import psycopg2
 try:
 conn = psycopg2.connect("dbname='postgres' user='postgres' 
 host='XXX.XXX.XXX.XXX' password='test' port=5432")
 cur = conn.cursor()
 cur.execute("UPDATE public.account SET username = %(username)s WHERE 
 user_id = 1;", {"username": "username-test-123"})
 cur.execute("COMMIT;")
 except Exception as e:
 print('Exception : {0}'.format(e))

 *Output:*

 Exception : value too long for type character varying(5)

 again data will not save in the table.

 These are some different behaviours with psycopg2. So to complete this 
 patch which apporach should I follow? or any new approach is also welcome.

 Thanks!



>
> Thanks,
> Khushboo
>
>
>
> On Tue, Apr 14, 2020 at 4:33 PM navnath gadakh <
> navnath.gad...@enterprisedb.com> wrote:
>
>> Hello Hackers,
>> Please find the attached patch for below fixes:
>>
>> - Added validation for table row data that should not be larger
>> than the field size.
>> - Rearrange the existing functions to add validation.
>> - Added test cases.
>>
>> Regards,
>> Navnath Gadakh
>>
>>

 --
 Regards,
 Navnath Gadakh

>>>
>
> --
> Regards,
> Navnath Gadakh
>


-- 
Dave Page
VP & Chief Architect, Database Infrastructure
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

Re: [pgAdmin][RM5210] pgAdmin4 silently truncates text larger than underlying field size

[Murtuza Zabuawala]

Hello,

We are sending the data to backend and depending on errors from backend. Any
thoughts on implementation of basic fronted validations? so that we can
alert user before it clicks on save button.


On Wed, 15 Apr 2020, 18:08 Dave Page,  wrote:

> Removing the typecast will almost certainly lead to other problems. I
> think we should just remove the length from it.
>
> On Wed, Apr 15, 2020 at 1:33 PM navnath gadakh <
> navnath.gad...@enterprisedb.com> wrote:
>
>> @Dave Page   @Akshay Joshi
>>  your input please?
>>
>> On Wed, Apr 15, 2020 at 3:13 PM Neel Patel 
>> wrote:
>>
>>> Hi,
>>>
>>> I think we should remove the type cast from query during update and
>>> whatever error is thrown should be shown to UI as per scenario 3.
>>>
>>> Thanks,
>>> Neel Patel
>>>
>>> On Wed, Apr 15, 2020 at 3:06 PM Khushboo Vashi <
>>> khushboo.va...@enterprisedb.com> wrote:
>>>


 On Wed, Apr 15, 2020 at 2:48 PM navnath gadakh <
 navnath.gad...@enterprisedb.com> wrote:

> Hello Hackers,
>
>
> On Tue, Apr 14, 2020 at 5:14 PM Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>> Hi Navnath,
>>
>> You have compared the column's internal size with the length of the
>> value given by the user.
>> For example, column having integer would have internal size 4 and if
>> I give the value 12121 which is the correct input for the field will fail
>> here because as per your logic column internal size (4) < len(value) (5).
>>
>> I think this implementation is not correct here.
>>
> Yes, my implementations might be wrong.
>
> Below are some important findings on the parameterised query(as we are
> using Jinja templates for building SQL queries).
> Here I have created a table 'account' with some records in it.
> CREATE TABLE public.account
> (
> user_id integer NOT NULL,
> username character varying(5)
> )
>
> psycopg2 throws a proper error if I pass username value greater than
> the length of the data type(5)
> Now, I want to pass username value greater than data type length (5)
>
> Scenario 1:  Query with data type and length
>
> import psycopg2
> try:
> conn = psycopg2.connect("dbname='postgres' user='postgres' 
> host='XXX.XXX.XXX.XXX' password='test' port=5432")
> cur = conn.cursor()
> cur.execute("UPDATE public.account SET username = 
> %(username)s::character varying(5) WHERE user_id = 1;", {"username": 
> "username-test-123"})
> cur.execute("COMMIT;")
> except Exception as e:
> print('Exception : {0}'.format(e))
>
> *Output:*
>
> It will save the record with 5 char data without any error.
>
> *psql output:*
>
> postgres=# select * from public.account;
>  user_id | username
> -+--
>1 | usern
> (1 row)
>
> Scenario 2:  Query with only data type
>
> import psycopg2
> try:
> conn = psycopg2.connect("dbname='postgres' user='postgres' 
> host='XXX.XXX.XXX.XXX' password='test' port=5432")
> cur = conn.cursor()
> cur.execute("UPDATE public.account SET username = 
> %(username)s::character varying WHERE user_id = 1;", {"username": 
> "username-test-123"})
> cur.execute("COMMIT;")
> except Exception as e:
> print('Exception : {0}'.format(e))
>
> *Output:*
>
> Exception : value too long for type character varying(5)
>
> data will not save in the table.
>
> We can consider scenario 2  as it will throw the valid exception and
 also typecast the value in the proper format.

> Scenario 3:  Query without data type
>
> import psycopg2
> try:
> conn = psycopg2.connect("dbname='postgres' user='postgres' 
> host='XXX.XXX.XXX.XXX' password='test' port=5432")
> cur = conn.cursor()
> cur.execute("UPDATE public.account SET username = %(username)s WHERE 
> user_id = 1;", {"username": "username-test-123"})
> cur.execute("COMMIT;")
> except Exception as e:
> print('Exception : {0}'.format(e))
>
> *Output:*
>
> Exception : value too long for type character varying(5)
>
> again data will not save in the table.
>
> These are some different behaviours with psycopg2. So to complete this 
> patch which apporach should I follow? or any new approach is also welcome.
>
> Thanks!
>
>
>
>>
>> Thanks,
>> Khushboo
>>
>>
>>
>> On Tue, Apr 14, 2020 at 4:33 PM navnath gadakh <
>> navnath.gad...@enterprisedb.com> wrote:
>>
>>> Hello Hackers,
>>> Please find the attached patch for below fixes:
>>>
>>> - Added validation for table row data that should not be larger
>>> than the field size.
>>> - Rearrange the existing functions to add validation.
>>> - Added test cases.
>

Re: [pgAdmin][RM5210] pgAdmin4 silently truncates text larger than underlying field size

[Ashesh Vashi]

On Wed, 15 Apr 2020 at 18:18, Murtuza Zabuawala <
murtuza.zabuaw...@enterprisedb.com> wrote:

> Hello,
>
> We are sending the data to backend and depending on errors from backend. Any
> thoughts on implementation of basic fronted validations? so that we can
> alert user before it clicks on save button.
>
We should not try to implement the database functionality in JavaScript.
One of the important reason for the same, we would never be able to
understand each and every types supported by PG/PEM.

— Ashesh


>
> On Wed, 15 Apr 2020, 18:08 Dave Page,  wrote:
>
>> Removing the typecast will almost certainly lead to other problems. I
>> think we should just remove the length from it.
>>
>> On Wed, Apr 15, 2020 at 1:33 PM navnath gadakh <
>> navnath.gad...@enterprisedb.com> wrote:
>>
>>> @Dave Page   @Akshay Joshi
>>>  your input please?
>>>
>>> On Wed, Apr 15, 2020 at 3:13 PM Neel Patel 
>>> wrote:
>>>
 Hi,

 I think we should remove the type cast from query during update and
 whatever error is thrown should be shown to UI as per scenario 3.

 Thanks,
 Neel Patel

 On Wed, Apr 15, 2020 at 3:06 PM Khushboo Vashi <
 khushboo.va...@enterprisedb.com> wrote:

>
>
> On Wed, Apr 15, 2020 at 2:48 PM navnath gadakh <
> navnath.gad...@enterprisedb.com> wrote:
>
>> Hello Hackers,
>>
>>
>> On Tue, Apr 14, 2020 at 5:14 PM Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>> Hi Navnath,
>>>
>>> You have compared the column's internal size with the length of the
>>> value given by the user.
>>> For example, column having integer would have internal size 4 and if
>>> I give the value 12121 which is the correct input for the field will 
>>> fail
>>> here because as per your logic column internal size (4) < len(value) 
>>> (5).
>>>
>>> I think this implementation is not correct here.
>>>
>> Yes, my implementations might be wrong.
>>
>> Below are some important findings on the parameterised query(as we
>> are using Jinja templates for building SQL queries).
>> Here I have created a table 'account' with some records in it.
>> CREATE TABLE public.account
>> (
>> user_id integer NOT NULL,
>> username character varying(5)
>> )
>>
>> psycopg2 throws a proper error if I pass username value greater than
>> the length of the data type(5)
>> Now, I want to pass username value greater than data type length (5)
>>
>> Scenario 1:  Query with data type and length
>>
>> import psycopg2
>> try:
>> conn = psycopg2.connect("dbname='postgres' user='postgres' 
>> host='XXX.XXX.XXX.XXX' password='test' port=5432")
>> cur = conn.cursor()
>> cur.execute("UPDATE public.account SET username = 
>> %(username)s::character varying(5) WHERE user_id = 1;", {"username": 
>> "username-test-123"})
>> cur.execute("COMMIT;")
>> except Exception as e:
>> print('Exception : {0}'.format(e))
>>
>> *Output:*
>>
>> It will save the record with 5 char data without any error.
>>
>> *psql output:*
>>
>> postgres=# select * from public.account;
>>  user_id | username
>> -+--
>>1 | usern
>> (1 row)
>>
>> Scenario 2:  Query with only data type
>>
>> import psycopg2
>> try:
>> conn = psycopg2.connect("dbname='postgres' user='postgres' 
>> host='XXX.XXX.XXX.XXX' password='test' port=5432")
>> cur = conn.cursor()
>> cur.execute("UPDATE public.account SET username = 
>> %(username)s::character varying WHERE user_id = 1;", {"username": 
>> "username-test-123"})
>> cur.execute("COMMIT;")
>> except Exception as e:
>> print('Exception : {0}'.format(e))
>>
>> *Output:*
>>
>> Exception : value too long for type character varying(5)
>>
>> data will not save in the table.
>>
>> We can consider scenario 2  as it will throw the valid exception and
> also typecast the value in the proper format.
>
>> Scenario 3:  Query without data type
>>
>> import psycopg2
>> try:
>> conn = psycopg2.connect("dbname='postgres' user='postgres' 
>> host='XXX.XXX.XXX.XXX' password='test' port=5432")
>> cur = conn.cursor()
>> cur.execute("UPDATE public.account SET username = %(username)s WHERE 
>> user_id = 1;", {"username": "username-test-123"})
>> cur.execute("COMMIT;")
>> except Exception as e:
>> print('Exception : {0}'.format(e))
>>
>> *Output:*
>>
>> Exception : value too long for type character varying(5)
>>
>> again data will not save in the table.
>>
>> These are some different behaviours with psycopg2. So to complete this 
>> patch which apporach should I follow? or any new approach is also 
>> welcome.
>>
>> Thanks!

Re: [pgAdmin][RM5210] pgAdmin4 silently truncates text larger than underlying field size

[Ashesh Vashi]

On Wed, 15 Apr 2020 at 18:21, Ashesh Vashi 
wrote:

>
>
> On Wed, 15 Apr 2020 at 18:18, Murtuza Zabuawala <
> murtuza.zabuaw...@enterprisedb.com> wrote:
>
>> Hello,
>>
>> We are sending the data to backend and depending on errors from backend. Any
>> thoughts on implementation of basic fronted validations? so that we can
>> alert user before it clicks on save button.
>>
> We should not try to implement the database functionality in JavaScript.
> One of the important reason for the same, we would never be able to
> understand each and every types supported by PG/PEM.
>
and - types from custom extensions.
So - no to that.

— Ashesh

>
> — Ashesh
>
>
>>
>> On Wed, 15 Apr 2020, 18:08 Dave Page,  wrote:
>>
>>> Removing the typecast will almost certainly lead to other problems. I
>>> think we should just remove the length from it.
>>>
>>> On Wed, Apr 15, 2020 at 1:33 PM navnath gadakh <
>>> navnath.gad...@enterprisedb.com> wrote:
>>>
 @Dave Page   @Akshay Joshi
  your input please?

 On Wed, Apr 15, 2020 at 3:13 PM Neel Patel 
 wrote:

> Hi,
>
> I think we should remove the type cast from query during update and
> whatever error is thrown should be shown to UI as per scenario 3.
>
> Thanks,
> Neel Patel
>
> On Wed, Apr 15, 2020 at 3:06 PM Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>>
>>
>> On Wed, Apr 15, 2020 at 2:48 PM navnath gadakh <
>> navnath.gad...@enterprisedb.com> wrote:
>>
>>> Hello Hackers,
>>>
>>>
>>> On Tue, Apr 14, 2020 at 5:14 PM Khushboo Vashi <
>>> khushboo.va...@enterprisedb.com> wrote:
>>>
 Hi Navnath,

 You have compared the column's internal size with the length of the
 value given by the user.
 For example, column having integer would have internal size 4 and
 if I give the value 12121 which is the correct input for the field will
 fail here because as per your logic column internal size (4) < 
 len(value)
 (5).

 I think this implementation is not correct here.

>>> Yes, my implementations might be wrong.
>>>
>>> Below are some important findings on the parameterised query(as we
>>> are using Jinja templates for building SQL queries).
>>> Here I have created a table 'account' with some records in it.
>>> CREATE TABLE public.account
>>> (
>>> user_id integer NOT NULL,
>>> username character varying(5)
>>> )
>>>
>>> psycopg2 throws a proper error if I pass username value greater than
>>> the length of the data type(5)
>>> Now, I want to pass username value greater than data type length (5)
>>>
>>> Scenario 1:  Query with data type and length
>>>
>>> import psycopg2
>>> try:
>>> conn = psycopg2.connect("dbname='postgres' user='postgres' 
>>> host='XXX.XXX.XXX.XXX' password='test' port=5432")
>>> cur = conn.cursor()
>>> cur.execute("UPDATE public.account SET username = 
>>> %(username)s::character varying(5) WHERE user_id = 1;", {"username": 
>>> "username-test-123"})
>>> cur.execute("COMMIT;")
>>> except Exception as e:
>>> print('Exception : {0}'.format(e))
>>>
>>> *Output:*
>>>
>>> It will save the record with 5 char data without any error.
>>>
>>> *psql output:*
>>>
>>> postgres=# select * from public.account;
>>>  user_id | username
>>> -+--
>>>1 | usern
>>> (1 row)
>>>
>>> Scenario 2:  Query with only data type
>>>
>>> import psycopg2
>>> try:
>>> conn = psycopg2.connect("dbname='postgres' user='postgres' 
>>> host='XXX.XXX.XXX.XXX' password='test' port=5432")
>>> cur = conn.cursor()
>>> cur.execute("UPDATE public.account SET username = 
>>> %(username)s::character varying WHERE user_id = 1;", {"username": 
>>> "username-test-123"})
>>> cur.execute("COMMIT;")
>>> except Exception as e:
>>> print('Exception : {0}'.format(e))
>>>
>>> *Output:*
>>>
>>> Exception : value too long for type character varying(5)
>>>
>>> data will not save in the table.
>>>
>>> We can consider scenario 2  as it will throw the valid exception and
>> also typecast the value in the proper format.
>>
>>> Scenario 3:  Query without data type
>>>
>>> import psycopg2
>>> try:
>>> conn = psycopg2.connect("dbname='postgres' user='postgres' 
>>> host='XXX.XXX.XXX.XXX' password='test' port=5432")
>>> cur = conn.cursor()
>>> cur.execute("UPDATE public.account SET username = %(username)s 
>>> WHERE user_id = 1;", {"username": "username-test-123"})
>>> cur.execute("COMMIT;")
>>> except Exception as e:
>>> print('Exception : {0}'.format(e))
>>>
>>> *Output:*
>>>
>>> Exception : value too long for type

[pgAdmin][RM5400] An unexpected occurred: INTERNAL SERVER ERROR message displayed if database server connected with non super user

[Aditya Toshniwal]

Hi Hackers,

Attached is the patch to replace the usage of pg_user_mapping table with
pg_user_mappings view. pg_user_mapping is not publicly accessible.
Changes are done for search objects and foreign data wrappers.
pgAdmin throws an exception when accessing User mappings with non
privileged users.
More about pg_user_mappings -
https://www.postgresql.org/docs/9.5/view-pg-user-mappings.html

Please review.

-- 
Thanks and Regards,
Aditya Toshniwal
pgAdmin Hacker | Sr. Software Engineer | EnterpriseDB India | Pune
"Don't Complain about Heat, Plant a TREE"


RM5400.patch
Description: Binary data

Re: [pgAdmin][RM5210] pgAdmin4 silently truncates text larger than underlying field size

[navnath gadakh]

Hi Khushboo,

 Please find the modified patch. I have removed the length from the data
types. Test cases also passing on all Postgres versions.
Thanks!



On Wed, Apr 15, 2020 at 6:22 PM Ashesh Vashi 
wrote:

>
>
> On Wed, 15 Apr 2020 at 18:21, Ashesh Vashi 
> wrote:
>
>>
>>
>> On Wed, 15 Apr 2020 at 18:18, Murtuza Zabuawala <
>> murtuza.zabuaw...@enterprisedb.com> wrote:
>>
>>> Hello,
>>>
>>> We are sending the data to backend and depending on errors from backend. Any
>>> thoughts on implementation of basic fronted validations? so that we can
>>> alert user before it clicks on save button.
>>>
>> We should not try to implement the database functionality in JavaScript.
>> One of the important reason for the same, we would never be able to
>> understand each and every types supported by PG/PEM.
>>
> and - types from custom extensions.
> So - no to that.
>
> — Ashesh
>
>>
>> — Ashesh
>>
>>
>>>
>>> On Wed, 15 Apr 2020, 18:08 Dave Page, 
>>> wrote:
>>>
 Removing the typecast will almost certainly lead to other problems. I
 think we should just remove the length from it.

 On Wed, Apr 15, 2020 at 1:33 PM navnath gadakh <
 navnath.gad...@enterprisedb.com> wrote:

> @Dave Page   @Akshay Joshi
>  your input please?
>
> On Wed, Apr 15, 2020 at 3:13 PM Neel Patel <
> neel.pa...@enterprisedb.com> wrote:
>
>> Hi,
>>
>> I think we should remove the type cast from query during update and
>> whatever error is thrown should be shown to UI as per scenario 3.
>>
>> Thanks,
>> Neel Patel
>>
>> On Wed, Apr 15, 2020 at 3:06 PM Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>>
>>>
>>> On Wed, Apr 15, 2020 at 2:48 PM navnath gadakh <
>>> navnath.gad...@enterprisedb.com> wrote:
>>>
 Hello Hackers,


 On Tue, Apr 14, 2020 at 5:14 PM Khushboo Vashi <
 khushboo.va...@enterprisedb.com> wrote:

> Hi Navnath,
>
> You have compared the column's internal size with the length of
> the value given by the user.
> For example, column having integer would have internal size 4 and
> if I give the value 12121 which is the correct input for the field 
> will
> fail here because as per your logic column internal size (4) < 
> len(value)
> (5).
>
> I think this implementation is not correct here.
>
 Yes, my implementations might be wrong.

 Below are some important findings on the parameterised query(as we
 are using Jinja templates for building SQL queries).
 Here I have created a table 'account' with some records in it.
 CREATE TABLE public.account
 (
 user_id integer NOT NULL,
 username character varying(5)
 )

 psycopg2 throws a proper error if I pass username value greater
 than the length of the data type(5)
 Now, I want to pass username value greater than data type length (5)

 Scenario 1:  Query with data type and length

 import psycopg2
 try:
 conn = psycopg2.connect("dbname='postgres' user='postgres' 
 host='XXX.XXX.XXX.XXX' password='test' port=5432")
 cur = conn.cursor()
 cur.execute("UPDATE public.account SET username = 
 %(username)s::character varying(5) WHERE user_id = 1;", {"username": 
 "username-test-123"})
 cur.execute("COMMIT;")
 except Exception as e:
 print('Exception : {0}'.format(e))

 *Output:*

 It will save the record with 5 char data without any error.

 *psql output:*

 postgres=# select * from public.account;
  user_id | username
 -+--
1 | usern
 (1 row)

 Scenario 2:  Query with only data type

 import psycopg2
 try:
 conn = psycopg2.connect("dbname='postgres' user='postgres' 
 host='XXX.XXX.XXX.XXX' password='test' port=5432")
 cur = conn.cursor()
 cur.execute("UPDATE public.account SET username = 
 %(username)s::character varying WHERE user_id = 1;", {"username": 
 "username-test-123"})
 cur.execute("COMMIT;")
 except Exception as e:
 print('Exception : {0}'.format(e))

 *Output:*

 Exception : value too long for type character varying(5)

 data will not save in the table.

 We can consider scenario 2  as it will throw the valid exception
>>> and also typecast the value in the proper format.
>>>
 Scenario 3:  Query without data type

 import psycopg2
 try:
 conn = psycopg2.connect("dbname='postgres' user='postgres' 
 host