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
