Re: Some pgAdmin bugs...

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

On Tue., 10 Sep. 2019, 9:56 pm Dave Page, <dpage(at)pgadmin(dot)org> wrote:

>
>
> On Tue, Sep 10, 2019 at 9:24 AM Arni Kromić <arni(dot)kromic(at)bios-ict(dot)hr>
> wrote:
>
>> On 10/09/2019 14.42, richard coleman wrote:
>>
>> Dave,
>>
>> While I agree it's generally a good idea to have a primary key, the
>> solution as currently implemented leaves the user unable to edit, or in
>> this case to even add a record to table without one. I would suggest
>> either having pgAdmin4 compute some sort of an *internal key* for cases
>> like this, or in the alternative *disable* those features (such as View/
>> *Edit*) that have not been implemented for cases such as this. Perhaps
>> with a dialog informing the user that "Editing or adding data isn't
>> supported on tables without a primary key".
>>
>> rik.
>>
>> I agree this is a corner case as mentioned. However, sometimes PK-s (or
>> indexes) are simply not needed, say if the table is insert-only most of the
>> time and its data gets dumped without any filters, and nothing ever needs
>> to be deleted. I believe Inserts should also work from pgAdmin as they do
>> from code.
>>
>> So, should a issue be raised, or is it already decided this is a
>> "wontfix"?
>>
>
> No, it's not decided. Feel free to add a feature request, but it's likely
> to be considered low priority.
>
>
>> --
>> Kind Regards,
>> Arni Kromić
>>
>>
>> On Tue, Sep 10, 2019 at 8:34 AM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>
>>>
>>>
>>> On Tue, Sep 10, 2019 at 8:24 AM richard coleman <
>>> rcoleman(dot)ascentgl(at)gmail(dot)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(dot)toshniwal(at)enterprisedb(dot)com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On Tue, Sep 10, 2019 at 5:13 PM Arni Kromić <arni(dot)kromic(at)bios-ict(dot)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 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
>