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 <dp...@pgadmin.org
> <mailto:dp...@pgadmin.org>> wrote:
>
>
>
>     On Tue, Sep 10, 2019 at 8:24 AM richard coleman
>     <rcoleman.ascen...@gmail.com <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
>         <aditya.toshni...@enterprisedb.com
>         <mailto:aditya.toshni...@enterprisedb.com>> wrote:
>
>             Hi,
>
>             On Tue, Sep 10, 2019 at 5:13 PM Arni Kromić
>             <arni.kro...@bios-ict.hr <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
>


Reply via email to