From: | Dave Page <dpage(at)pgadmin(dot)org> |
---|---|
To: | Yosry Muhammad <yosrym93(at)gmail(dot)com> |
Cc: | pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org> |
Subject: | Re: [GSoC] Ideas for the remaining of the project |
Date: | 2019-07-15 08:56:35 |
Message-ID: | CA+OCxow5FJ0N9ibbgsqkcqfibMOX+xRm6zm3hDCdfeaYB5UsOQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgadmin-hackers |
Hi
On Mon, Jul 15, 2019 at 2:02 AM Yosry Muhammad <yosrym93(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2019-07-15 09:25:08 | pgAdmin 4 commit: Add Reverse Engineered SQL tests for Types. Fixes #44 |
Previous Message | Murtuza Zabuawala | 2019-07-15 06:57:16 | [RM#4468] Add RE-SQL tests for Type node |