On 10/09/2019 18.36, Avin Kavish wrote: > Isn't there some internal uniqueness tracking mechanism? Object IDs or > something? > > On Tue., 10 Sep. 2019, 9:56 pm Dave Page, <dp...@pgadmin.org > <mailto:dp...@pgadmin.org>> wrote: > > > > On Tue, Sep 10, 2019 at 9:24 AM Arni Kromić > <arni.kro...@bios-ict.hr <mailto: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. > Great, I think I'll do it, for the sake of completeness. I believe there is no need to create workarounds for updates and/or deletes in this case; they should remain disabled when there is no PK. Just inserts (the "empty row" in this case) should be made possible.
> > > ... > > > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > -- Kind Regards, Arni Kromić
