Hi On Thursday, November 30, 2017, Khushboo Vashi < khushboo.va...@enterprisedb.com> wrote:
> Hi, > > Please find the attached updated patch. > > On Mon, Nov 27, 2017 at 5:15 PM, Dave Page <dp...@pgadmin.org > <javascript:_e(%7B%7D,'cvml','dp...@pgadmin.org');>> wrote: > >> Hi >> >> On Thu, Nov 23, 2017 at 1:28 PM, Khushboo Vashi < >> khushboo.va...@enterprisedb.com >> <javascript:_e(%7B%7D,'cvml','khushboo.va...@enterprisedb.com');>> wrote: >> >>> Hi, >>> >>> Please find the attached patch for RM #2849: Allow editing of data on >>> tables with OIDs but no primary key. >>> >> >> I like that if I add a new row or rows and hit Save, the OIDs are fetched >> immediately. However; >> >> - It marks the row as read-only. We do that currently because we don't >> return the key info on Save, and thus require a Refresh before any further >> editing. However, if we have the OID, we can edit again immediately. >> >> Fixed > >> - If we can return the new OIDs on Save, can't we do the same for primary >> key values? That would be consistent with OIDs, and would remove the need >> to disable rows, leading to a much nicer use experience I think. >> >> Implemented > This looks great, however there is one small issue I spotted; it looks like we're inserting rows in a random order. For example, in the screenshot attached, the last 5 rows were added in the order seen in the key1 column, and then I hit Save and got the id values returned. Is that caused by something we're doing, or the database server? Thanks! -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
