Hi On Mon, Jul 15, 2019 at 2:02 AM Yosry Muhammad <yosry...@gmail.com> wrote:
> Hi Dave, > > The core patch for this project is being finalized and I am unable to work > for the current few days due to issues mentioned in the previous email. > Therefore, I have been thinking of what can be done in the project after > this patch is done. > > Below are the features I have been thinking of with a short description > (ordered by priority in my point of view): > > 1- Supporting tables that have OIDs rather than primary keys (I have a bit > of research to do about OIDs and how they work). > They're going to need special treatment in 12+, but for older versions it's quite simple; if they exist on a table, they can be considered a unique row identifier. > > 2- Modifying the way table information is sent from the backend, and the > way they are processed in the frontend. > > This will include (but is not limited to) modifying the columns info sent > to the frontend to include: > - Whether the column is a primary key (instead of matching by name at the > frontend). > - Whether the individual column is editable. This means there could be > editable resultsets with read-only columns. It will allow for supporting a > wider range of resultsets, such as: queries selecting some columns from a > table in addition to an aggregation performed on one or more of the > columns, queries with renamed columns, etc. > > It will also include modifying how columns info is handled in the frontend. > Sure - handling editable resultsets with read-only columns should definitely be part of this project, and I agree that will mean altering the way data is sent from the backend. It's important to keep it as efficient as possible as well; with large resultsets we've found in the past that the data size can be a real issue and previously worked on ways to improve efficiency. > > 3- Mogirfying queries generated by pgAdmin during saving data changes to > be able to display them in a meaningful way to the user. Moreover, a > checkbox/preferences option is to be added to enable/disable showing them > in the query history (to be discussed further upon implementation). This > will involve modifying the cursor and connection wrapper classes in the > backend to add a mogrify function wrapper in addition to other changes > throughout the code. > Agreed; I think those three parts are very meaningful enhancements to the work you've already done and will lead to a very successful GSoC project. Let's get the final few tweaks done to the first patch, then move on. I'd love to see that work committed this week. Thanks - and keep up the good work! -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
