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 <dp...@pgadmin.org> wrote: > > > On Tue, Sep 10, 2019 at 12:36 PM Avin Kavish <avinkav...@gmail.com> 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, <dp...@pgadmin.org> wrote: >> >>> >>> >>> On Tue, Sep 10, 2019 at 9:24 AM Arni Kromić <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. >>> >>> >>>> -- >>>> Kind Regards, >>>> Arni Kromić >>>> >>>> >>>> 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 >>>>> >>>> >>>> >>>> >>> >>> -- >>> 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 >
