public inbox for [email protected]
help / color / mirror / Atom feed[GSoC] Ideas for the remaining of the project
2+ messages / 2 participants
[nested] [flat]
* [GSoC] Ideas for the remaining of the project
@ 2019-07-15 01:02 Yosry Muhammad <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Yosry Muhammad @ 2019-07-15 01:02 UTC (permalink / raw)
To: Dave Page <[email protected]>; +Cc: pgadmin-hackers
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).
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.
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.
Please let me know what you think of this. Looking forward to feedback,
suggestions and comments.
Thanks and regards.
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: [GSoC] Ideas for the remaining of the project
@ 2019-07-15 08:56 Dave Page <[email protected]>
parent: Yosry Muhammad <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Dave Page @ 2019-07-15 08:56 UTC (permalink / raw)
To: Yosry Muhammad <[email protected]>; +Cc: pgadmin-hackers
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
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2019-07-15 08:56 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2019-07-15 01:02 [GSoC] Ideas for the remaining of the project Yosry Muhammad <[email protected]>
2019-07-15 08:56 ` Dave Page <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox