Re: [GSoC] Ideas for the remaining of the project

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

In response to

Browse pgadmin-hackers by date

  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