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 <dp...@pgadmin.org> 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 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 >
