Thread: pgAdmin III - Editing data
pgAdmin III July 16th Build.
OS: W2K SP4
There are loads of issues here and so I will start with just a few:
1) The only way to edit data is via view data. If I have a table that has 2000000 records I don't want to load them all into a view.
The old pgAdmin II had the ability to edit data from any result set query that you execute.
With this later method provided by pgAdmin II, one has total flexibility over selecting only a range of data and also allowing one to order the data in some sensible way.
Currently with pgAdmin III there is no ordering or ability to limit the data in the view for editing.
2) If I attempt to edit a column and then change my mind one would assume that pressing "Esc" would cancel editing. Not so with pgAdmin III, as soon as you change rows pgAdmin III automatically attempts to update the edited column/s. If I press the "return" key after editing a column pgAdmin III automatically attempts to save the column - fair enough, but then why doesn't "Esc" cancel editing?
I would have thought that the button - "Save the changed row", found on the tool bar of the view, would be sufficient. I know there is a button "Undo changed data", but I would prefer to have user instantiated save changes rather than automatic. (Only my opinion I know)
3) Not possible to edit multiple line data.
4) If I have a NULL integer value and I try and set it to zero I cannot. I have to set it to some other value first, like 1, and then set it to zero.
Regards
Donald Fraser
Donald Fraser wrote: > pgAdmin III July 16th Build. > > OS: W2K SP4 > > There are loads of issues here and so I will start with just a few: > > 1) The only way to edit data is via view data. If I have a table that > has 2000000 records I don't want to load them all into a view. > The old pgAdmin II had the ability to edit data from any result set > query that you execute. > With this later method provided by pgAdmin II, one has total > flexibility over selecting only a range of data and also allowing one > to order the data in some sensible way. > Currently with pgAdmin III there is no ordering or ability to limit > the data in the view for editing. There's a TODO item for this. pgAdmin2 didn't manage the result set, but instead would reexecute the given query. This could result in unexpected behaviour. Imagine you had a "... where foo < 200", and now you change a row's foo to 205. After refresh, the row will be gone. While this is technically correct, it's quite irritating. Due to the complete reexecution, no primary key is necessary. In contrast, pgAdmin3's implementation will do updates based on primary keys (or oid, if available). You can't extract this information from a generic query. There's internal discussion about the focused audience for pgAdmin3's View Data tool. While I see that there are additional wishes about a tool to manipulate data, I consider this to be an additional tool for data manipulation. Stay tuned. > > 2) If I attempt to edit a column and then change my mind one would > assume that pressing "Esc" would cancel editing. Not so with pgAdmin > III, as soon as you change rows pgAdmin III automatically attempts to > update the edited column/s. If I press the "return" key after editing > a column pgAdmin III automatically attempts to save the column - fair > enough, but then why doesn't "Esc" cancel editing? > I would have thought that the button - "Save the changed row", found > on the tool bar of the view, would be sufficient. I know there is a > button "Undo changed data", but I would prefer to have > user instantiated save changes rather than automatic. (Only my opinion > I know) You're right, there are complications about keyboard handling in conjunction with the inplace editing functionality. > > 3) Not possible to edit multiple line data. It is! Try resizing the row, and use Ctrl-Return to enter a newline. This info was missing in the documentation. > > 4) If I have a NULL integer value and I try and set it to zero I > cannot. I have to set it to some other value first, like 1, and then > set it to zero. Hm, seems the "changed data" check fails... will look at that. Regards, Andreas