Re: Some pgAdmin bugs...

From: Dave Page <dpage(at)pgadmin(dot)org>
To: Arni Kromić <arni(dot)kromic(at)bios-ict(dot)hr>
Cc: "pgadmin-support lists(dot)postgresql(dot)org" <pgadmin-support(at)lists(dot)postgresql(dot)org>
Subject: Re: Some pgAdmin bugs...
Date: 2019-09-10 16:00:44
Message-ID: CA+OCxow1qwtwHwEft2vnFG62OKU4y=ObU_iq_QDWa-+vLQyM4A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-support

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

In response to

Responses

Browse pgadmin-support by date

  From Date Subject
Next Message Avin Kavish 2019-09-10 16:36:37 Re: Some pgAdmin bugs...
Previous Message Arni Kromić 2019-09-10 13:24:25 Re: Some pgAdmin bugs...