Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hmwn1-0005Pg-Cc for pgadmin-hackers@arkaria.postgresql.org; Mon, 15 Jul 2019 08:56:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hmwmz-0001gd-UA for pgadmin-hackers@arkaria.postgresql.org; Mon, 15 Jul 2019 08:56:53 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hmwmz-0001gW-De for pgadmin-hackers@lists.postgresql.org; Mon, 15 Jul 2019 08:56:53 +0000 Received: from mail-wm1-x341.google.com ([2a00:1450:4864:20::341]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hmwmw-0001RC-CH for pgadmin-hackers@postgresql.org; Mon, 15 Jul 2019 08:56:52 +0000 Received: by mail-wm1-x341.google.com with SMTP id a15so14279321wmj.5 for ; Mon, 15 Jul 2019 01:56:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pyJgcqn88Jra8qFHf/Jyvz9n0lYRmXwZ0ile4sL/ZPE=; b=PgRLCn371YVnO1xam7DjNg1CAmCOqOeZSd8QU7SiAfSI2SVHY8ZxM8CE0uOhgOzq5r /5dgw2EHLkEV47/VG8F+mqPfOk9cUQsAeFZqwcd6YSTE6fVclyTc+0y92CLNTmGulUjD fa6Fs4AujOksnhLAmqBHsITycDbe3+M/BCx9eUMzGwEVnGwzQNNhuOadY+HXehIXgMQ3 vK/cFtQ7U5tZpIY/uZPgtXzGAwlMBdfp/Qf/x7MVR8tC254GGmdAunV4khGl9ZFyUsDV LbvjJtK+PvcG3ps96KM52wwRDuivTJe3TWLKRmRLnAwoBsdiqZ8RUdWlrzI5IFFVY+s7 VGbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pyJgcqn88Jra8qFHf/Jyvz9n0lYRmXwZ0ile4sL/ZPE=; b=d2OLeKc46LI+TR2vKZYm/zmccieeAnFyOguYGFv9o7W04TXGAEaGqAIlrqmyL1zMnt 1n0Nr7fAG+k72JVz7FfycJl4S4I70oc9wMoUmc3WpuYwuw1qxsAvdYBFgSxCzJOJAHcF fhVdoODZMfSGPjCDypTDHM4tz7naSTKoF2bmlaiZemGloQTfp5/XTB8Z31uKS5sZn2oa mBIAHnpROxN4lrcbCwstanLDQd+3iPhjufk+uHjU0cpd4tg7V91gbo2CNn2gYYVcnCOe thW0ql6DSkGs6AHqMXX8jE1bhH28fREdrYzX4dvsy5db7n6Ip/aoamx7P3E8asZnnFuq 5Z9A== X-Gm-Message-State: APjAAAUy5DNK8QNmW37kHudkA4wEpNHzGO/zvmOmKA8ljVUnILRDmM8F bhfHzsnelObB8nEvFKDoRCkWRLUuaodllpYM6w3EDYSL0UE= X-Google-Smtp-Source: APXvYqyFmH/4G5mrWoJJtI0d8WHyc0/S79sL8YJkwnNuERALDULNV0HZSrjn6QviBDtCHC+gVaF20CF2hiYrnSiY8ng= X-Received: by 2002:a1c:f018:: with SMTP id a24mr22768100wmb.66.1563181007558; Mon, 15 Jul 2019 01:56:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Page Date: Mon, 15 Jul 2019 09:56:35 +0100 Message-ID: Subject: Re: [GSoC] Ideas for the remaining of the project To: Yosry Muhammad Cc: pgadmin-hackers Content-Type: multipart/alternative; boundary="000000000000ace8a0058db470de" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --000000000000ace8a0058db470de Content-Type: text/plain; charset="UTF-8" Hi On Mon, Jul 15, 2019 at 2:02 AM Yosry Muhammad 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 --000000000000ace8a0058db470de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

On Mon, Jul 15, 2019 at 2:02 AM Yosry Muhammad <= yosrym93@gmail.com> wrote:
=
H= i Dave,

The core patch for thi= s project is being finalized and I am unable to work for the current few da= ys due to issues mentioned in the previous email. Therefore, I have been th= inking of what can be done in the project after this patch is done.

Below are the features I have b= een thinking of with a short description (ordered by priority in my point o= f view):

1- Supporting t= ables 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 versio= ns it's quite simple; if they exist on a table, they can be considered = a unique row identifier.
=C2=A0

2- Modifying the way table information is sent from the backend,= and the way they are processed in the frontend.=C2=A0

This will include (but is not limited to) mo= difying 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 e= ditable. This means there could be editable resultsets with read-only colum= ns. It will allow for supporting a wider range of resultsets, such as: quer= ies selecting some columns from a table in addition to an aggregation perfo= rmed on one or more of the columns, queries with renamed columns, etc.

It will also include modifyi= ng 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 alte= ring the way data is sent from the backend. It's important to keep it a= s efficient as possible as well; with large resultsets we've found in t= he past that the data size can be a real issue and previously worked on way= s to improve efficiency.
=C2=A0

3- Mogirfying queries generated by pgAdmin during saving data ch= anges 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 the= m in the query history (to be discussed further upon implementation). This = will involve modifying the cursor and connection wrapper classes in the bac= kend to add a mogrify function wrapper in addition to other changes through= out the code.

Agreed; I think t= hose three parts are very meaningful enhancements to the work you've al= ready done and will lead to a very successful GSoC project.

<= /div>
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.

<= /div>
Thanks - and keep up the good work!=C2=A0

--
Dave Page
Blog: http://pgsnake.blogs= pot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
= The Enterprise PostgreSQL Company
--000000000000ace8a0058db470de--