Обсуждение: Some pgAdmin bugs...

Working with pgAdmin, I've found several bugs. Not sure if they are already reported; couldn't find them on Redmine, but perhaps I missed them. Maybe someone will recognize if they've already been reported. Here it goes...

1) When doing View/Edit on an empty table, I cannot insert anything when it opens. There is no empty row I can write into, like there is when a table has at least one row already. In fact, there are no rows at all, just the header.

2) Create Sequence dialog doesn't accept negative values for Increment (Error msg:

Increment' must be greater than or equal to 1.) Postgres does accept negative increment, so should this dialog.

3) EXEC Script context menu for Procedures works incorrectly - doesn't write the script to the end. An example, procedure with many parameters:

CREATE OR REPLACE PROCEDURE public.dodaj_klijenta(	v_naziv character varying,	v_oib character varying,	v_pdv_id character varying,	v_adresa character varying,	v_mjesto integer,	v_drzava character varying,	v_tip_p_sub character varying,	v_vlasnik character varying,	v_pdv boolean,	v_fisk boolean,	v_iban character varying,	v_k_osoba character varying,	v_email character varying,	v_br_tel character varying,	v_radna_god numeric,	v_schema character varying)
...

The EXEC Script for it is generated exactly thus:

CALL public.dodaj_klijenta(	<v_naziv character varying>, 	<v_oib character varyi>

As you can see, it is cut off very early.
A notice, this is only for procedures; EXEC Scripts for functions with many arguments work fine.

4) This one is not a biggie, but it would be nice if it is fixed. Code inserted in the Code tab of the Create/Properties dialog for functions and procedures is put within $BODY$ tags without any newlines. So, if I write a new function/procedure and write this in the editor on the Code tab (shown together with line numbers I see):

1 select * from keyring
2 --some comment

The function is created containing this:

...
AS $BODY$select * from keyring
--tralala$BODY$;
...

Although it apparently doesn't harm the code, it is visually ugly and the syntax-highlighting colors the second line as comment, so the closing $BODY$ appears commented (a bit confusing to see). So to make it look normal, I have to prepend and append a newline:

1 
2 select * from keyring
3 --some comment
4

...to get a more acceptable code:

...
AS $BODY$
select * from keyring
--tralala
$BODY$;
...

So I propose those newlines should be added automatically.


Please advise if I need to report the above problems on Redmine, or perhaps do something else...

-- 
Kind Regards,
Arni Kromić

Hi,

On Tue, Sep 10, 2019 at 5:13 PM Arni Kromić <arni.kromic@bios-ict.hr> wrote:

Working with pgAdmin, I've found several bugs. Not sure if they are already reported; couldn't find them on Redmine, but perhaps I missed them. Maybe someone will recognize if they've already been reported. Here it goes...

1) When doing View/Edit on an empty table, I cannot insert anything when it opens. There is no empty row I can write into, like there is when a table has at least one row already. In fact, there are no rows at all, just the header.

I tried. I get an empty row to enter

 

2) Create Sequence dialog doesn't accept negative values for Increment (Error msg:

Increment' must be greater than or equal to 1.) Postgres does accept negative increment, so should this dialog.

Kindly raise here - https://redmine.postgresql.org/projects/pgadmin4/issues/new 

3) EXEC Script context menu for Procedures works incorrectly - doesn't write the script to the end. An example, procedure with many parameters:

Its a bug - Kindly raise here - https://redmine.postgresql.org/projects/pgadmin4/issues/new 

CREATE OR REPLACE PROCEDURE public.dodaj_klijenta(	v_naziv character varying,	v_oib character varying,	v_pdv_id character varying,	v_adresa character varying,	v_mjesto integer,	v_drzava character varying,	v_tip_p_sub character varying,	v_vlasnik character varying,	v_pdv boolean,	v_fisk boolean,	v_iban character varying,	v_k_osoba character varying,	v_email character varying,	v_br_tel character varying,	v_radna_god numeric,	v_schema character varying)
...

The EXEC Script for it is generated exactly thus:

CALL public.dodaj_klijenta(	<v_naziv character varying>, 	<v_oib character varyi>

As you can see, it is cut off very early.
A notice, this is only for procedures; EXEC Scripts for functions with many arguments work fine.

4) This one is not a biggie, but it would be nice if it is fixed. Code inserted in the Code tab of the Create/Properties dialog for functions and procedures is put within $BODY$ tags without any newlines. So, if I write a new function/procedure and write this in the editor on the Code tab (shown together with line numbers I see):

Yes. Its been logged - https://redmine.postgresql.org/issues/3851 

1 select * from keyring
2 --some comment

The function is created containing this:

...
AS $BODY$select * from keyring
--tralala$BODY$;
...

Although it apparently doesn't harm the code, it is visually ugly and the syntax-highlighting colors the second line as comment, so the closing $BODY$ appears commented (a bit confusing to see). So to make it look normal, I have to prepend and append a newline:

1 
2 select * from keyring
3 --some comment
4

...to get a more acceptable code:

...
AS $BODY$
select * from keyring
--tralala
$BODY$;
...

So I propose those newlines should be added automatically.


Please advise if I need to report the above problems on Redmine, or perhaps do something else...

-- 
Kind Regards,
Arni Kromić

--

Thanks and Regards,

Aditya Toshniwal

Software Engineer | EnterpriseDB India | Pune

"Don't Complain about Heat, Plant a TREE"

On Tue, Sep 10, 2019 at 5:29 PM Aditya Toshniwal <aditya.toshniwal@enterprisedb.com> wrote:

Hi,

On Tue, Sep 10, 2019 at 5:13 PM Arni Kromić <arni.kromic@bios-ict.hr> wrote:

Working with pgAdmin, I've found several bugs. Not sure if they are already reported; couldn't find them on Redmine, but perhaps I missed them. Maybe someone will recognize if they've already been reported. Here it goes...

1) When doing View/Edit on an empty table, I cannot insert anything when it opens. There is no empty row I can write into, like there is when a table has at least one row already. In fact, there are no rows at all, just the header.

I tried. I get an empty row to enter

 

If the table doesn't have primary key, then empty row will *NOT* be there. 

2) Create Sequence dialog doesn't accept negative values for Increment (Error msg:

Increment' must be greater than or equal to 1.) Postgres does accept negative increment, so should this dialog.

Kindly raise here - https://redmine.postgresql.org/projects/pgadmin4/issues/new 

3) EXEC Script context menu for Procedures works incorrectly - doesn't write the script to the end. An example, procedure with many parameters:

Its a bug - Kindly raise here - https://redmine.postgresql.org/projects/pgadmin4/issues/new 

CREATE OR REPLACE PROCEDURE public.dodaj_klijenta(	v_naziv character varying,	v_oib character varying,	v_pdv_id character varying,	v_adresa character varying,	v_mjesto integer,	v_drzava character varying,	v_tip_p_sub character varying,	v_vlasnik character varying,	v_pdv boolean,	v_fisk boolean,	v_iban character varying,	v_k_osoba character varying,	v_email character varying,	v_br_tel character varying,	v_radna_god numeric,	v_schema character varying)
...

The EXEC Script for it is generated exactly thus:

CALL public.dodaj_klijenta(	<v_naziv character varying>, 	<v_oib character varyi>

As you can see, it is cut off very early.
A notice, this is only for procedures; EXEC Scripts for functions with many arguments work fine.

4) This one is not a biggie, but it would be nice if it is fixed. Code inserted in the Code tab of the Create/Properties dialog for functions and procedures is put within $BODY$ tags without any newlines. So, if I write a new function/procedure and write this in the editor on the Code tab (shown together with line numbers I see):

Yes. Its been logged - https://redmine.postgresql.org/issues/3851 

1 select * from keyring
2 --some comment

The function is created containing this:

...
AS $BODY$select * from keyring
--tralala$BODY$;
...

Although it apparently doesn't harm the code, it is visually ugly and the syntax-highlighting colors the second line as comment, so the closing $BODY$ appears commented (a bit confusing to see). So to make it look normal, I have to prepend and append a newline:

1 
2 select * from keyring
3 --some comment
4

...to get a more acceptable code:

...
AS $BODY$
select * from keyring
--tralala
$BODY$;
...

So I propose those newlines should be added automatically.


Please advise if I need to report the above problems on Redmine, or perhaps do something else...

-- 
Kind Regards,
Arni Kromić

--

Thanks and Regards,

Aditya Toshniwal

Software Engineer | EnterpriseDB India | Pune

"Don't Complain about Heat, Plant a TREE"

Hi,

On Tue, Sep 10, 2019 at 5:13 PM Arni Kromić <arni.kromic@bios-ict.hr> wrote:

Working with pgAdmin, I've found several bugs. Not sure if they are already reported; couldn't find them on Redmine, but perhaps I missed them. Maybe someone will recognize if they've already been reported. Here it goes...

1) When doing View/Edit on an empty table, I cannot insert anything when it opens. There is no empty row I can write into, like there is when a table has at least one row already. In fact, there are no rows at all, just the header.

I tried. I get an empty row to enter

 

Hi All, 

My $0.02.  Tested the first one here (Kubuntu 18.04, Chromium, pgAdmin 4 4.12) with mixed results.

On Tue, Sep 10, 2019 at 7:59 AM Aditya Toshniwal <aditya.toshniwal@enterprisedb.com> wrote:

Hi,

On Tue, Sep 10, 2019 at 5:13 PM Arni Kromić <arni.kromic@bios-ict.hr> wrote:

Working with pgAdmin, I've found several bugs. Not sure if they are already reported; couldn't find them on Redmine, but perhaps I missed them. Maybe someone will recognize if they've already been reported. Here it goes...

1) When doing View/Edit on an empty table, I cannot insert anything when it opens. There is no empty row I can write into, like there is when a table has at least one row already. In fact, there are no rows at all, just the header.

I tried. I get an empty row to enter

 

Test table0: two columns both character varying columns, no primary key, View/Edit opens without any rows as the original poster Arni wrote.

Test table1: three columns, two character varying, one primary key bigint, View/Edit opens with a single blank row as Aditya reported.

Does Arni's table have a primary key defined?  Is it a bigint?  It looks like there might be a bug where pgAdmin4 isn't presenting a row to add a record from the View/Edit function if there isn't a primary key, or a particular type of primary key defined on the table.

On 10/09/2019 14.42, richard coleman wrote:

Dave, 

While I agree it's generally a good idea to have a primary key, the solution as currently implemented leaves the user unable to edit, or in this case to even add a record to table without one.  I would suggest either having pgAdmin4 compute some sort of an internal key for cases like this, or in the alternative disable those features (such as View/Edit) that have not been implemented for cases such as this.  Perhaps with a dialog informing the user that "Editing or adding data isn't supported on tables without a primary key".

rik.

I agree this is a corner case as mentioned. However, sometimes PK-s (or indexes) are simply not needed, say if the table is insert-only most of the time and its data gets dumped without any filters, and nothing ever needs to be deleted. I believe Inserts should also work from pgAdmin as they do from code.

So, should a issue be raised, or is it already decided this is a "wontfix"?

-- 
Kind Regards,
Arni Kromić

On Tue, Sep 10, 2019 at 8:34 AM Dave Page <dpage@pgadmin.org> wrote:

On Tue, Sep 10, 2019 at 8:24 AM richard coleman <rcoleman.ascentgl@gmail.com> wrote:

Hi All, 

My $0.02.  Tested the first one here (Kubuntu 18.04, Chromium, pgAdmin 4 4.12) with mixed results.

On Tue, Sep 10, 2019 at 7:59 AM Aditya Toshniwal <aditya.toshniwal@enterprisedb.com> wrote:

Hi,

On Tue, Sep 10, 2019 at 5:13 PM Arni Kromić <arni.kromic@bios-ict.hr> wrote:

Working with pgAdmin, I've found several bugs. Not sure if they are already reported; couldn't find them on Redmine, but perhaps I missed them. Maybe someone will recognize if they've already been reported. Here it goes...

1) When doing View/Edit on an empty table, I cannot insert anything when it opens. There is no empty row I can write into, like there is when a table has at least one row already. In fact, there are no rows at all, just the header.

I tried. I get an empty row to enter

 

Test table0: two columns both character varying columns, no primary key, View/Edit opens without any rows as the original poster Arni wrote.

Test table1: three columns, two character varying, one primary key bigint, View/Edit opens with a single blank row as Aditya reported.

Does Arni's table have a primary key defined?  Is it a bigint?  It looks like there might be a bug where pgAdmin4 isn't presenting a row to add a record from the View/Edit function if there isn't a primary key, or a particular type of primary key defined on the table.

If memory serves that was a design choice when the code was implemented. We cannot safely allow editing without a primary key, and adding rows (which arguably is safe) is considered editing as the code is currently implemented.

I consider this a corner-case; typically one would have a primary key on a table to identify individual rows, and most cases where you wouldn't are probably not ones where you'd ever try to edit or manually add data (consider something like sensor output data). I'm not sure how much demand there would be for doing this; clearly not a huge amount.

--

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

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

Isn't there some internal uniqueness tracking mechanism? Object IDs or something?

On Tue., 10 Sep. 2019, 9:56 pm Dave Page, <dpage@pgadmin.org> wrote:

On Tue, Sep 10, 2019 at 9:24 AM Arni Kromić <arni.kromic@bios-ict.hr> wrote:

On 10/09/2019 14.42, richard coleman wrote:

Dave, 

While I agree it's generally a good idea to have a primary key, the solution as currently implemented leaves the user unable to edit, or in this case to even add a record to table without one.  I would suggest either having pgAdmin4 compute some sort of an internal key for cases like this, or in the alternative disable those features (such as View/Edit) that have not been implemented for cases such as this.  Perhaps with a dialog informing the user that "Editing or adding data isn't supported on tables without a primary key".

rik.

I agree this is a corner case as mentioned. However, sometimes PK-s (or indexes) are simply not needed, say if the table is insert-only most of the time and its data gets dumped without any filters, and nothing ever needs to be deleted. I believe Inserts should also work from pgAdmin as they do from code.

So, should a issue be raised, or is it already decided this is a "wontfix"?

No, it's not decided. Feel free to add a feature request, but it's likely to be considered low priority.

 

-- 
Kind Regards,
Arni Kromić

On Tue, Sep 10, 2019 at 8:34 AM Dave Page <dpage@pgadmin.org> wrote:

On Tue, Sep 10, 2019 at 8:24 AM richard coleman <rcoleman.ascentgl@gmail.com> wrote:

Hi All, 

My $0.02.  Tested the first one here (Kubuntu 18.04, Chromium, pgAdmin 4 4.12) with mixed results.

On Tue, Sep 10, 2019 at 7:59 AM Aditya Toshniwal <aditya.toshniwal@enterprisedb.com> wrote:

Hi,

On Tue, Sep 10, 2019 at 5:13 PM Arni Kromić <arni.kromic@bios-ict.hr> wrote:

Working with pgAdmin, I've found several bugs. Not sure if they are already reported; couldn't find them on Redmine, but perhaps I missed them. Maybe someone will recognize if they've already been reported. Here it goes...

1) When doing View/Edit on an empty table, I cannot insert anything when it opens. There is no empty row I can write into, like there is when a table has at least one row already. In fact, there are no rows at all, just the header.

I tried. I get an empty row to enter

 

Test table0: two columns both character varying columns, no primary key, View/Edit opens without any rows as the original poster Arni wrote.

Test table1: three columns, two character varying, one primary key bigint, View/Edit opens with a single blank row as Aditya reported.

Does Arni's table have a primary key defined?  Is it a bigint?  It looks like there might be a bug where pgAdmin4 isn't presenting a row to add a record from the View/Edit function if there isn't a primary key, or a particular type of primary key defined on the table.

If memory serves that was a design choice when the code was implemented. We cannot safely allow editing without a primary key, and adding rows (which arguably is safe) is considered editing as the code is currently implemented.

I consider this a corner-case; typically one would have a primary key on a table to identify individual rows, and most cases where you wouldn't are probably not ones where you'd ever try to edit or manually add data (consider something like sensor output data). I'm not sure how much demand there would be for doing this; clearly not a huge amount.

--

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

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

--

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

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

Thanks for educating me there Dave, do you also know why and when this decision was made?

On Tue, Sep 10, 2019 at 10:17 PM Dave Page <dpage@pgadmin.org> wrote:

On Tue, Sep 10, 2019 at 12:36 PM Avin Kavish <avinkavish@gmail.com> wrote:

Isn't there some internal uniqueness tracking mechanism? Object IDs or something?

OIDs are deprecated and have been for years. They're removed from user tables entirely from v12.

 

On Tue., 10 Sep. 2019, 9:56 pm Dave Page, <dpage@pgadmin.org> wrote:

On Tue, Sep 10, 2019 at 9:24 AM Arni Kromić <arni.kromic@bios-ict.hr> wrote:

On 10/09/2019 14.42, richard coleman wrote:

Dave, 

While I agree it's generally a good idea to have a primary key, the solution as currently implemented leaves the user unable to edit, or in this case to even add a record to table without one.  I would suggest either having pgAdmin4 compute some sort of an internal key for cases like this, or in the alternative disable those features (such as View/Edit) that have not been implemented for cases such as this.  Perhaps with a dialog informing the user that "Editing or adding data isn't supported on tables without a primary key".

rik.

I agree this is a corner case as mentioned. However, sometimes PK-s (or indexes) are simply not needed, say if the table is insert-only most of the time and its data gets dumped without any filters, and nothing ever needs to be deleted. I believe Inserts should also work from pgAdmin as they do from code.

So, should a issue be raised, or is it already decided this is a "wontfix"?

No, it's not decided. Feel free to add a feature request, but it's likely to be considered low priority.

 

-- 
Kind Regards,
Arni Kromić

On Tue, Sep 10, 2019 at 8:34 AM Dave Page <dpage@pgadmin.org> wrote:

On Tue, Sep 10, 2019 at 8:24 AM richard coleman <rcoleman.ascentgl@gmail.com> wrote:

Hi All, 

My $0.02.  Tested the first one here (Kubuntu 18.04, Chromium, pgAdmin 4 4.12) with mixed results.

On Tue, Sep 10, 2019 at 7:59 AM Aditya Toshniwal <aditya.toshniwal@enterprisedb.com> wrote:

Hi,

On Tue, Sep 10, 2019 at 5:13 PM Arni Kromić <arni.kromic@bios-ict.hr> wrote:

Working with pgAdmin, I've found several bugs. Not sure if they are already reported; couldn't find them on Redmine, but perhaps I missed them. Maybe someone will recognize if they've already been reported. Here it goes...

1) When doing View/Edit on an empty table, I cannot insert anything when it opens. There is no empty row I can write into, like there is when a table has at least one row already. In fact, there are no rows at all, just the header.

I tried. I get an empty row to enter

 

Test table0: two columns both character varying columns, no primary key, View/Edit opens without any rows as the original poster Arni wrote.

Test table1: three columns, two character varying, one primary key bigint, View/Edit opens with a single blank row as Aditya reported.

Does Arni's table have a primary key defined?  Is it a bigint?  It looks like there might be a bug where pgAdmin4 isn't presenting a row to add a record from the View/Edit function if there isn't a primary key, or a particular type of primary key defined on the table.

If memory serves that was a design choice when the code was implemented. We cannot safely allow editing without a primary key, and adding rows (which arguably is safe) is considered editing as the code is currently implemented.

I consider this a corner-case; typically one would have a primary key on a table to identify individual rows, and most cases where you wouldn't are probably not ones where you'd ever try to edit or manually add data (consider something like sensor output data). I'm not sure how much demand there would be for doing this; clearly not a huge amount.

--

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

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

--

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

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

--

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

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