Some pgAdmin bugs...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Some pgAdmin bugs...

Arni Kromić
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ć
Reply | Threaded
Open this post in threaded view
|

Re: Some pgAdmin bugs...

Arni Kromić
On 10/09/2019 13.43, Arni Kromić 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...

Forgot to mention software version, it's pgAdmin 4.12 installed from the
upstream apt repo on Ubuntu 18.04LTS.

--
Kind Regards,
Arni Kromić



Reply | Threaded
Open this post in threaded view
|

Re: Some pgAdmin bugs...

Aditya Toshniwal
In reply to this post by Arni Kromić
Hi,

On Tue, Sep 10, 2019 at 5:13 PM Arni Kromić <[hidden email]> 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
Screenshot 2019-09-10 at 17.25.25.png
 

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ć


--
Thanks and Regards,
Aditya Toshniwal
Software Engineer | EnterpriseDB India | Pune
"Don't Complain about Heat, Plant a TREE"
Reply | Threaded
Open this post in threaded view
|

Re: Some pgAdmin bugs...

Khushboo Vashi


On Tue, Sep 10, 2019 at 5:29 PM Aditya Toshniwal <[hidden email]> wrote:
Hi,

On Tue, Sep 10, 2019 at 5:13 PM Arni Kromić <[hidden email]> 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
Screenshot 2019-09-10 at 17.25.25.png
 
If the table doesn't have primary key, then empty row will 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.

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ć


--
Thanks and Regards,
Aditya Toshniwal
Software Engineer | EnterpriseDB India | Pune
"Don't Complain about Heat, Plant a TREE"
Reply | Threaded
Open this post in threaded view
|

Re: Some pgAdmin bugs...

Khushboo Vashi


On Tue, Sep 10, 2019 at 5:33 PM Khushboo Vashi <[hidden email]> wrote:


On Tue, Sep 10, 2019 at 5:29 PM Aditya Toshniwal <[hidden email]> wrote:
Hi,

On Tue, Sep 10, 2019 at 5:13 PM Arni Kromić <[hidden email]> 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
Screenshot 2019-09-10 at 17.25.25.png
 
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.

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ć


--
Thanks and Regards,
Aditya Toshniwal
Software Engineer | EnterpriseDB India | Pune
"Don't Complain about Heat, Plant a TREE"
Reply | Threaded
Open this post in threaded view
|

Re: Some pgAdmin bugs...

richard coleman
In reply to this post by Aditya Toshniwal
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 <[hidden email]> wrote:
Hi,

On Tue, Sep 10, 2019 at 5:13 PM Arni Kromić <[hidden email]> 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
Screenshot 2019-09-10 at 17.25.25.png
 
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.

I hope that helps, 

rik.
Reply | Threaded
Open this post in threaded view
|

Re: Some pgAdmin bugs...

Dave Page-7


On Tue, Sep 10, 2019 at 8:24 AM richard coleman <[hidden email]> 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 <[hidden email]> wrote:
Hi,

On Tue, Sep 10, 2019 at 5:13 PM Arni Kromić <[hidden email]> 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
Screenshot 2019-09-10 at 17.25.25.png
 
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
Reply | Threaded
Open this post in threaded view
|

Re: Some pgAdmin bugs...

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

On Tue, Sep 10, 2019 at 8:34 AM Dave Page <[hidden email]> wrote:


On Tue, Sep 10, 2019 at 8:24 AM richard coleman <[hidden email]> 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 <[hidden email]> wrote:
Hi,

On Tue, Sep 10, 2019 at 5:13 PM Arni Kromić <[hidden email]> 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
Screenshot 2019-09-10 at 17.25.25.png
 
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
Reply | Threaded
Open this post in threaded view
|

Re: Some pgAdmin bugs...

Arni Kromić
In reply to this post by Aditya Toshniwal
On 10/09/2019 13.58, Aditya Toshniwal wrote:
Hi,

On Tue, Sep 10, 2019 at 5:13 PM Arni Kromić <[hidden email]> 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
Screenshot 2019-09-10 at 17.25.25.png
 

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.
Done: https://redmine.postgresql.org/issues/4726


3) EXEC Script context menu for Procedures works incorrectly - doesn't write the script to the end. An example, procedure with many parameters:
Here it is: https://redmine.postgresql.org/issues/4727

...

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):
Great! I hope at least the missing newlines will be fixed soon. :)

...

-- 
Kind Regards,
Arni Kromić


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


-- 
Kind Regards,
Arni Kromić
Reply | Threaded
Open this post in threaded view
|

Re: Some pgAdmin bugs...

Arni Kromić
In reply to this post by richard coleman
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 <[hidden email]> wrote:


On Tue, Sep 10, 2019 at 8:24 AM richard coleman <[hidden email]> 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 <[hidden email]> wrote:
Hi,

On Tue, Sep 10, 2019 at 5:13 PM Arni Kromić <[hidden email]> 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
Screenshot 2019-09-10 at
                              17.25.25.png
 
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



  



	
	
	
	
Reply | Threaded
Open this post in threaded view
|

Re: Some pgAdmin bugs...

Dave Page-7


On Tue, Sep 10, 2019 at 9:24 AM Arni Kromić <[hidden email]> 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 <[hidden email]> wrote:


On Tue, Sep 10, 2019 at 8:24 AM richard coleman <[hidden email]> 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 <[hidden email]> wrote:
Hi,

On Tue, Sep 10, 2019 at 5:13 PM Arni Kromić <[hidden email]> 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
Screenshot 2019-09-10 at
                              17.25.25.png
 
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
Reply | Threaded
Open this post in threaded view
|

Re: Some pgAdmin bugs...

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

On Tue., 10 Sep. 2019, 9:56 pm Dave Page, <[hidden email]> wrote:


On Tue, Sep 10, 2019 at 9:24 AM Arni Kromić <[hidden email]> 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 <[hidden email]> wrote:


On Tue, Sep 10, 2019 at 8:24 AM richard coleman <[hidden email]> 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 <[hidden email]> wrote:
Hi,

On Tue, Sep 10, 2019 at 5:13 PM Arni Kromić <[hidden email]> 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
Screenshot 2019-09-10 at
                              17.25.25.png
 
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
Reply | Threaded
Open this post in threaded view
|

Re: Some pgAdmin bugs...

Dave Page-7


On Tue, Sep 10, 2019 at 12:36 PM Avin Kavish <[hidden email]> 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, <[hidden email]> wrote:


On Tue, Sep 10, 2019 at 9:24 AM Arni Kromić <[hidden email]> 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 <[hidden email]> wrote:


On Tue, Sep 10, 2019 at 8:24 AM richard coleman <[hidden email]> 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 <[hidden email]> wrote:
Hi,

On Tue, Sep 10, 2019 at 5:13 PM Arni Kromić <[hidden email]> 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
Screenshot 2019-09-10 at
                              17.25.25.png
 
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
Reply | Threaded
Open this post in threaded view
|

Re: Some pgAdmin bugs...

Arni Kromić
In reply to this post by Avin Kavish
On 10/09/2019 18.36, Avin Kavish wrote:
Isn't there some internal uniqueness tracking mechanism? Object IDs or something?

On Tue., 10 Sep. 2019, 9:56 pm Dave Page, <[hidden email]> wrote:


On Tue, Sep 10, 2019 at 9:24 AM Arni Kromić <[hidden email]> 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.
Great, I think I'll do it, for the sake of completeness. I believe there is no need to create workarounds for updates and/or deletes in this case; they should remain disabled when there is no PK. Just inserts (the "empty row" in this case) should be made possible.

 
...



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

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

-- 
Kind Regards,
Arni Kromić
Reply | Threaded
Open this post in threaded view
|

Re: Some pgAdmin bugs...

Avin Kavish
In reply to this post by Dave Page-7
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 <[hidden email]> wrote:


On Tue, Sep 10, 2019 at 12:36 PM Avin Kavish <[hidden email]> 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, <[hidden email]> wrote:


On Tue, Sep 10, 2019 at 9:24 AM Arni Kromić <[hidden email]> 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 <[hidden email]> wrote:


On Tue, Sep 10, 2019 at 8:24 AM richard coleman <[hidden email]> 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 <[hidden email]> wrote:
Hi,

On Tue, Sep 10, 2019 at 5:13 PM Arni Kromić <[hidden email]> 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
Screenshot 2019-09-10 at
                              17.25.25.png
 
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
Reply | Threaded
Open this post in threaded view
|

Re: Some pgAdmin bugs...

Dave Page-7


On Wed, Sep 11, 2019 at 6:35 AM Avin Kavish <[hidden email]> wrote:
Thanks for educating me there Dave, do you also know why and when this decision was made?

OIDs come from a global 32 bit counter. That has overhead of course (locking), and it wraps around at ~4 billion so you cannot guarantee uniqueness if you use them in a table. They are still used in system tables in 12.x, but a column called oid in v12 and later is treated like any other column.

The deprecation process started with the release of PostgreSQL 8.0 on January 19 2005, which made them optional, but on by default, and then in 8.1 (November 8 2005) they defaulted to off and were noted in the release notes as being deprecated over the use of SERIAL columns for generated keys. 

So, users have had about 14 years to prepare... :-)
 

On Tue, Sep 10, 2019 at 10:17 PM Dave Page <[hidden email]> wrote:


On Tue, Sep 10, 2019 at 12:36 PM Avin Kavish <[hidden email]> 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, <[hidden email]> wrote:


On Tue, Sep 10, 2019 at 9:24 AM Arni Kromić <[hidden email]> 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 <[hidden email]> wrote:


On Tue, Sep 10, 2019 at 8:24 AM richard coleman <[hidden email]> 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 <[hidden email]> wrote:
Hi,

On Tue, Sep 10, 2019 at 5:13 PM Arni Kromić <[hidden email]> 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
Screenshot 2019-09-10 at
                              17.25.25.png
 
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


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

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