public inbox for [email protected]
help / color / mirror / Atom feedFrom: Dave Page <[email protected]>
To: Yosry Muhammad <[email protected]>
Cc: pgadmin-hackers <[email protected]>
Subject: Re: [GSoC] Ideas for the remaining of the project
Date: Mon, 15 Jul 2019 09:56:35 +0100
Message-ID: <CA+OCxow5FJ0N9ibbgsqkcqfibMOX+xRm6zm3hDCdfeaYB5UsOQ@mail.gmail.com> (raw)
In-Reply-To: <CAFSMqn9VyRDyyDOGaJY2xhDpe3y9V=-Stzz2MmzBHZ8wrvunDw@mail.gmail.com>
References: <CAFSMqn9VyRDyyDOGaJY2xhDpe3y9V=-Stzz2MmzBHZ8wrvunDw@mail.gmail.com>
Hi
On Mon, Jul 15, 2019 at 2:02 AM Yosry Muhammad <[email protected]> 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
view thread (2+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: [GSoC] Ideas for the remaining of the project
In-Reply-To: <CA+OCxow5FJ0N9ibbgsqkcqfibMOX+xRm6zm3hDCdfeaYB5UsOQ@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox