Re: Some pgAdmin bugs...

[Dave Page]

On Wed, Sep 11, 2019 at 6:35 AM Avin Kavish  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  wrote:
>
>>
>>
>> On Tue, Sep 10, 2019 at 12:36 PM Avin Kavish 
>> 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,  wrote:
>>>


 On Tue, Sep 10, 2019 at 9:24 AM Arni Kromić 
 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  wrote:
>
>>
>>
>> On Tue, Sep 10, 2019 at 8:24 AM richard coleman <
>> rcoleman.ascen...@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.toshni...@enterprisedb.com> wrote:
>>>
 Hi,

 On Tue, Sep 10, 2019 at 5:13 PM Arni Kromić <
 arni.kro...@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
 [image: 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

Re: Some pgAdmin bugs...

[Avin Kavish]

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

>
>
> On Tue, Sep 10, 2019 at 12:36 PM Avin Kavish  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,  wrote:
>>
>>>
>>>
>>> On Tue, Sep 10, 2019 at 9:24 AM Arni Kromić 
>>> 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  wrote:

>
>
> On Tue, Sep 10, 2019 at 8:24 AM richard coleman <
> rcoleman.ascen...@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.toshni...@enterprisedb.com> wrote:
>>
>>> Hi,
>>>
>>> On Tue, Sep 10, 2019 at 5:13 PM 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...

 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
>>> [image: 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
>

Re: Some pgAdmin bugs...

[Arni Kromić]

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,  > wrote:
>
>
>
> On Tue, Sep 10, 2019 at 9:24 AM Arni Kromić
> mailto:arni.kro...@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.
>
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ć

Re: Some pgAdmin bugs...

[Dave Page]

On Tue, Sep 10, 2019 at 12:36 PM Avin Kavish  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,  wrote:
>
>>
>>
>> On Tue, Sep 10, 2019 at 9:24 AM Arni Kromić 
>> 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  wrote:
>>>


 On Tue, Sep 10, 2019 at 8:24 AM richard coleman <
 rcoleman.ascen...@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.toshni...@enterprisedb.com> wrote:
>
>> Hi,
>>
>> On Tue, Sep 10, 2019 at 5:13 PM 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...
>>>
>>> 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
>> [image: 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

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

>
>
> On Tue, Sep 10, 2019 at 9:24 AM Arni Kromić 
> 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  wrote:
>>
>>>
>>>
>>> On Tue, Sep 10, 2019 at 8:24 AM richard coleman <
>>> rcoleman.ascen...@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.toshni...@enterprisedb.com> wrote:

> Hi,
>
> On Tue, Sep 10, 2019 at 5:13 PM 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...
>>
>> 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
> [image: 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
>

Re: Some pgAdmin bugs...

[Dave Page]

On Tue, Sep 10, 2019 at 9:24 AM Arni Kromić  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  wrote:
>
>>
>>
>> On Tue, Sep 10, 2019 at 8:24 AM richard coleman <
>> rcoleman.ascen...@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.toshni...@enterprisedb.com> wrote:
>>>
 Hi,

 On Tue, Sep 10, 2019 at 5:13 PM 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...
>
> 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
 [image: 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

Re: Some pgAdmin bugs...

[Arni Kromić]

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  > wrote:
>
>
>
> On Tue, Sep 10, 2019 at 8:24 AM richard coleman
> mailto:rcoleman.ascen...@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
>  > wrote:
>
> Hi,
>
> On Tue, Sep 10, 2019 at 5:13 PM Arni Kromić
> mailto:arni.kro...@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
> 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
>

Re: Some pgAdmin bugs...

[Arni Kromić]

On 10/09/2019 13.58, Aditya Toshniwal wrote:
> Hi,
>
> On Tue, Sep 10, 2019 at 5:13 PM 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...
>
> 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.
>
> Kindly raise here
> - https://redmine.postgresql.org/projects/pgadmin4/issues/new
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:
>
> Its a bug - Kindly raise here
> - https://redmine.postgresql.org/projects/pgadmin4/issues/new
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):
>
> Yes. Its been logged - https://redmine.postgresql.org/issues/3851
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ć

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

>
>
> On Tue, Sep 10, 2019 at 8:24 AM richard coleman <
> rcoleman.ascen...@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.toshni...@enterprisedb.com> wrote:
>>
>>> Hi,
>>>
>>> On Tue, Sep 10, 2019 at 5:13 PM 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...

 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
>>> [image: 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
>

Re: Some pgAdmin bugs...

[Dave Page]

On Tue, Sep 10, 2019 at 8:24 AM richard coleman 
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.toshni...@enterprisedb.com> wrote:
>
>> Hi,
>>
>> On Tue, Sep 10, 2019 at 5:13 PM 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...
>>>
>>> 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
>> [image: 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

Re: Some pgAdmin bugs...

[richard coleman]

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.toshni...@enterprisedb.com> wrote:

> Hi,
>
> On Tue, Sep 10, 2019 at 5:13 PM 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...
>>
>> 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
> [image: 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.

>

Re: Some pgAdmin bugs...

[Khushboo Vashi]

On Tue, Sep 10, 2019 at 5:33 PM Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

>
>
> On Tue, Sep 10, 2019 at 5:29 PM Aditya Toshniwal <
> aditya.toshni...@enterprisedb.com> wrote:
>
>> Hi,
>>
>> On Tue, Sep 10, 2019 at 5:13 PM 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...
>>>
>>> 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
>> [image: 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.
>>>
>> 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(
>>> ,
>>> 
>>>
>>> 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"
>>
>

Re: Some pgAdmin bugs...

[Khushboo Vashi]

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

> Hi,
>
> On Tue, Sep 10, 2019 at 5:13 PM 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...
>>
>> 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
> [image: 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.
>>
> 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(
>>  ,
>>  
>>
>> 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"
>

Re: Some pgAdmin bugs...

[Aditya Toshniwal]

Hi,

On Tue, Sep 10, 2019 at 5:13 PM 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...
>
> 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
[image: 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.
>
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(
>   ,
>   
>
> 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"

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ć