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 1hdpKO-0000Kg-O1 for pgadmin-hackers@arkaria.postgresql.org; Thu, 20 Jun 2019 05:09:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hdpKM-00082i-Nh for pgadmin-hackers@arkaria.postgresql.org; Thu, 20 Jun 2019 05:09:38 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hdpKL-0007xr-VL for pgadmin-hackers@lists.postgresql.org; Thu, 20 Jun 2019 05:09:38 +0000 Received: from mail-ot1-x329.google.com ([2607:f8b0:4864:20::329]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hdpKD-0005Xi-Kq for pgadmin-hackers@postgresql.org; Thu, 20 Jun 2019 05:09:36 +0000 Received: by mail-ot1-x329.google.com with SMTP id i8so1454277oth.10 for ; Wed, 19 Jun 2019 22:09:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jadSLMQg4Ot2buyzOgNygp92jHufzSQTzHZlDL6brfk=; b=fVxBgxq2qx50TLRfR5BCCEBWhjIq81CI6MNRZpCVjXJKnNoVOAgvg2sHuD+2MQkFhU 98Sua2mzznYTomvsFovHHuchMBLo3tDc8Lc75wLcnaRoXYtAs9us5E/qIObfT0BD8M9C ORFN1jiEO268ADIdUMOywDR8sL3pLQGYt2NnP1+Q6AfeR6EJhRWWS4W/KtBAha9SvAx5 j5wWtVW/saN7hqCXmFfZ7mlCytjCQViWsl279ydYvaQna7lRMZ8Rat8Iu3QKDkjEPj8p GVUz4AajAzU6Se/zO4XfRLizggOmxFwQMz/4V2ooGkyo9oWpLRdCVKK//4/viNBULM1p w4oA== 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=jadSLMQg4Ot2buyzOgNygp92jHufzSQTzHZlDL6brfk=; b=YH8bU7n/v9JYw3KqzMxwtNXWazNZelnm+qrE8v72LjdUOhGNDNLdt/DJSbxC2Z1NwL YYimhoxI8l9vjZE2cIabVdQwXniiAcjUNAPSVZ5qU72z/ss5xGYalbMZVeDMwGIrtETt pCQw1g3a8FaYRnNjSniCCuIesshwdMI1HY17tSJPtlfPpJibXvVehoB/NOxvsL1NkW8l PEqfM4wBV9rV7uQLboyOeRnAlA3i/QPQN/iRYLt/XBMcSAFaE+fFOqdZVaPU11afAS0J buRSv/UwVTbOS0gis5SraHzduZjelusZbW7ZZchXCOFemu2vbYRCwwdV13Y1mxOWnGaF xagw== X-Gm-Message-State: APjAAAWNDXdfeNhBKJhDLpMeIkmGrE/RTpbEf/+UZ25XDj4YDS+zN/Hl Q+BDSQomCIYD9iQU06C4gy9ywpF4Teyx2lUxr29Q1Q== X-Google-Smtp-Source: APXvYqxx+2OQW+fFGwGxDvpmf66n6pU6IRwNziZCZW4p9sfCjecv6BAXGuCGUoYRb3C9kVJPshgii1erusBSXWZO3/4= X-Received: by 2002:a9d:69d6:: with SMTP id v22mr10987784oto.212.1561007368529; Wed, 19 Jun 2019 22:09:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Murtuza Zabuawala Date: Thu, 20 Jun 2019 10:39:17 +0530 Message-ID: Subject: Re: [GSoC][Patch] Automatic Mode Detection V1 To: Yosry Muhammad Cc: Dave Page , pgadmin-hackers Content-Type: multipart/alternative; boundary="000000000000b17f70058bba595a" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --000000000000b17f70058bba595a Content-Type: text/plain; charset="UTF-8" On Thu, Jun 20, 2019 at 2:20 AM Yosry Muhammad wrote: > Hi there ! > > On Wed, Jun 19, 2019 at 4:11 PM Dave Page wrote: > >> >>> - We need to think about how data editing fits in with transaction >>> control. Right now, it seems to happen entirely outside of it - for >>> example, I tend to work with auto commit turned off, so my connection sits >>> idle-in-transaction following an initial select, and remains un-affected by >>> edits. Please think about this and suggest options for us to discuss. >>> >>> >>> I integrated the data editing in the transaction control as you noted. >>> Now the behavior is as follows: >>> 1- In View Data mode, same existing behavior. >>> 2- In Query Tool mode: >>> - If auto-commit is on: the modifications are made and commited once >>> save is pressed. >>> - If auto-commit is off: the modifications are made as part of the >>> ongoing transaction (or a new one if no transaction is ongoing), they are >>> not commited unless the user executes a commit command (or rollback). >>> >>> >>> That seems to work. I think we need to make it more obvious that there's >>> a transaction in progress - especially as that can be the case after the >>> user hits the Save button and thinks their data is safe (a side-thought is >>> that perhaps we shouldn't require the Save button to be pressed when >>> auto-commit is turned off, as that's just odd). We should highlight the >>> transaction state more clearly to the user, and make sure we prompt for >>> confirmation if they try to close the tab or the whole window. >>> >>> >>> The transaction status can be made more obvious and point out when a >>> transaction is in progress that changes aren't commited. However, removing >>> the save button when auto commit is off will cause us to a send a request >>> and execute a query every time any cell is changed (which can be by >>> accident or some kind of draft). I also think it will make more sense when >>> there is a dedicated button, which can be named such that it is clear that >>> it only executes some queries. Also, the pop up that shows after edits are >>> succeesful can also state thar these changes are not yet commited. >>> >> >> Yeah, I agree removing the button for some modes only is weird. Maybe >> adding info to the notification, and having a more prominent "Your >> transaction is still in progress" notification will be enough. >> > > Will work on adding a notification and making the transaction status more > prominent. > > >> >> Another thought - we also need to figure out what happens if the user >> edits data in the grid and when saving, an error occurs (e.g. trying to >> insert null into a not-null field). How does that tie into transaction >> control? For example, auto-rollback may then revert other changes made via >> SQL (which should have been atomic, with the data changes) - or having >> auto-rollback turned off may then require the user to explicitly start a >> new transaction before attempting to save the data again. Perhaps we need >> to precede data changes with a savepoint, and then roll back to that if >> there's an error? >> > > I think the savepoint is an adequate solution.If any problems happen then > rollback to the savepoint then release it, else just release the savepoint. > > >> I think it makes more sense for filters to be disabled. I mean since the >>> user is already writing SQL it would be more convenient to just edit it >>> directly. >>> >>> >>> Well we're not going to just disable them - we'll either remove them, or >>> try to make them work. I'm leaning strongly towards just removing that code >>> entirely. >>> >>> >>> I meant disabling them in the query tool while keeping them in the View >>> Data mode as the user cannot edit the sql in the View Data mode. Do you >>> want to remove the feature from both modes completely? >>> >>> >>> I think you misunderstand - I want to remove the View Data mode >>> entirely. Your work should replace it. >>> >>> >>> As a user of pgAdmin I think this might not be the best option. Not all >>> users of pgAdmin are developers or know SQL. I worked on several projects >>> before where other people on the team (or frontend developers) would just >>> want to take a look at some data or do simple edits using the GUI. Also, >>> other management studios for other DBMSs also allow for this. In addition, >>> the user can do sorting of data without knowing SQL. What I think can be >>> done (potentially - maybe in the future) is limit the dependance on SQL >>> knowledge when doing filters in View Data mode, while disabling filters and >>> so in the Query Tool. >>> >> +1 View data mode is quick & easy way for any novice user who want to interact with table data. >> Hmm, the point of this project (which has been a goal for maybe 20 >> years!) was to remove that mode entirely. There is an argument that users >> can use the "SELECT Script" option instead if they don't know SQL, but that >> would still require the Sort/Filter options. >> >> What do other folks think? >> > > Waiting for other people's opinion on that matter. > > Oh, and icon attached! >> > > Will work on adding the new icon and switching the save functionality to > it. I propose using this icon to save data in both View Data and Query Tool > mode, and the existing save button for exclusively saving the query files > (will be disabled in View Data mode). > > On Wed, Jun 19, 2019 at 4:11 PM Dave Page wrote: > >> Hi >> >> On Wed, Jun 19, 2019 at 2:47 PM Yosry Muhammad >> wrote: >> >>> Hi, >>> >>> >>> On Wed, Jun 19, 2019, 1:54 PM Dave Page wrote: >>> . >>> >>> - We need to add a "do you want to continue" warning before actions like >>> Execute or EXPLAIN are run, if there are unsaved changes in the grid. >>> >>> - I think we should make the text in any cells that has been edited bold >>> until saved, so the user can see where changes have been made (as they can >>> with deleted rows). >>> >>> >>> Both done, new rows are highlighted too. >>> >>> >>> Nice! I realise it's most likely not your code, but if you can fix the >>> wrapping so it doesn't break mid-word, that would be good. See the attached >>> screenshot to see what I mean. >>> >>> >>> >>> Will do. >>> >>> >>> - If I make two data edits and then delete a row, I get 3 entries in the >>> History panel, all showing the same delete. I would actually argue that >>> data edit queries that pgAdmin generates should not go into the History at >>> all, but maybe they should be added albeit with a flag to say they're >>> internal queries and an option to hide them. Thoughts? >>> >>> >>> That was a bug with the existing 'save changes' action of 'View Data', >>> on which mine is based upon. I fixed the bug, now the queries are shown >>> correctly. However, the queries are shown in the form in which they are >>> sent from the backend to the database driver (without parameters - also an >>> already existing bug in View Data Mode), for example: >>> >>> INSERT INTO public.kweek ( >>> media_url, username, text, created_at) VALUES ( >>> %(media_url)s::character varying, %(username)s::character varying, >>> %(text)s::text, %(created_at)s::timestamp without time zone) >>> returning id; >>> >>> >>> I propose two solutions: >>> 1- Hide pgadmin's generated sql from history (in both modes). >>> 2- Show the actual sql query that was executed after the parameters are >>> plugged in (more understandable and potentially helpful). >>> >>> >>> I like the idea of doing 2 - but I think we should have a checkbox on >>> the history panel to show/hide generated queries (and we should include >>> transaction control - BEGIN, COMMIT etc - in the generated query class). >>> >>> >>> >>> I can work on option 2 now and then work on >>> the checkbox if/when there is time. >>> >> >> I'm pretty sure there will be time :-) >> >> >>> >>> >>> >>> - We need to think about how data editing fits in with transaction >>> control. Right now, it seems to happen entirely outside of it - for >>> example, I tend to work with auto commit turned off, so my connection sits >>> idle-in-transaction following an initial select, and remains un-affected by >>> edits. Please think about this and suggest options for us to discuss. >>> >>> >>> I integrated the data editing in the transaction control as you noted. >>> Now the behavior is as follows: >>> 1- In View Data mode, same existing behavior. >>> 2- In Query Tool mode: >>> - If auto-commit is on: the modifications are made and commited once >>> save is pressed. >>> - If auto-commit is off: the modifications are made as part of the >>> ongoing transaction (or a new one if no transaction is ongoing), they are >>> not commited unless the user executes a commit command (or rollback). >>> >>> >>> That seems to work. I think we need to make it more obvious that there's >>> a transaction in progress - especially as that can be the case after the >>> user hits the Save button and thinks their data is safe (a side-thought is >>> that perhaps we shouldn't require the Save button to be pressed when >>> auto-commit is turned off, as that's just odd). We should highlight the >>> transaction state more clearly to the user, and make sure we prompt for >>> confirmation if they try to close the tab or the whole window. >>> >>> >>> The transaction status can be made more obvious and point out when a >>> transaction is in progress that changes aren't commited. However, removing >>> the save button when auto commit is off will cause us to a send a request >>> and execute a query every time any cell is changed (which can be by >>> accident or some kind of draft). I also think it will make more sense when >>> there is a dedicated button, which can be named such that it is clear that >>> it only executes some queries. Also, the pop up that shows after edits are >>> succeesful can also state thar these changes are not yet commited. >>> >> >> Yeah, I agree removing the button for some modes only is weird. Maybe >> adding info to the notification, and having a more prominent "Your >> transaction is still in progress" notification will be enough. >> >> Another thought - we also need to figure out what happens if the user >> edits data in the grid and when saving, an error occurs (e.g. trying to >> insert null into a not-null field). How does that tie into transaction >> control? For example, auto-rollback may then revert other changes made via >> SQL (which should have been atomic, with the data changes) - or having >> auto-rollback turned off may then require the user to explicitly start a >> new transaction before attempting to save the data again. Perhaps we need >> to precede data changes with a savepoint, and then roll back to that if >> there's an error? >> >> >>> >>> I think it makes more sense for filters to be disabled. I mean since the >>> user is already writing SQL it would be more convenient to just edit it >>> directly. >>> >>> >>> Well we're not going to just disable them - we'll either remove them, or >>> try to make them work. I'm leaning strongly towards just removing that code >>> entirely. >>> >>> >>> I meant disabling them in the query tool while keeping them in the View >>> Data mode as the user cannot edit the sql in the View Data mode. Do you >>> want to remove the feature from both modes completely? >>> >>> >>> I think you misunderstand - I want to remove the View Data mode >>> entirely. Your work should replace it. >>> >>> >>> As a user of pgAdmin I think this might not be the best option. Not all >>> users of pgAdmin are developers or know SQL. I worked on several projects >>> before where other people on the team (or frontend developers) would just >>> want to take a look at some data or do simple edits using the GUI. Also, >>> other management studios for other DBMSs also allow for this. In addition, >>> the user can do sorting of data without knowing SQL. What I think can be >>> done (potentially - maybe in the future) is limit the dependance on SQL >>> knowledge when doing filters in View Data mode, while disabling filters and >>> so in the Query Tool. >>> >> >> Hmm, the point of this project (which has been a goal for maybe 20 >> years!) was to remove that mode entirely. There is an argument that users >> can use the "SELECT Script" option instead if they don't know SQL, but that >> would still require the Sort/Filter options. >> >> What do other folks think? >> >> Oh, and icon attached! >> >> -- >> Dave Page >> Blog: http://pgsnake.blogspot.com >> Twitter: @pgsnake >> >> EnterpriseDB UK: http://www.enterprisedb.com >> The Enterprise PostgreSQL Company >> > > > -- > *Yosry Muhammad Yosry* > > Computer Engineering student, > The Faculty of Engineering, > Cairo University (2021). > Class representative of CMP 2021. > https://www.linkedin.com/in/yosrym93/ > --000000000000b17f70058bba595a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 20, 2019 at 2:20 AM = Yosry Muhammad <yosrym93@gmail.com= > wrote:
H= i there !

On Wed, Jun= 19, 2019 at 4:11 PM Dave Page <dpage@pgadmin.org> wrote:
=

- We need to think about how data editing fits in with transaction=20 control. Right now, it seems to happen entirely outside of it - for=20 example, I tend to work with auto commit turned off, so my connection=20 sits idle-in-transaction following an initial select, and remains=20 un-affected by edits. Please think about this and suggest options for us to discuss.

I integrated= the data editing in the transaction control as you noted. Now the behavior= is as follows:
1- In View Data mode, same existing behavior.=
2- In Query Tool mode:
- If auto-commit is on: the mod= ifications are made and commited once save is pressed.
- If auto-commit is off: the modifications are made as part of the=20 ongoing transaction (or a new one if no transaction is ongoing), they=20 are not commited unless the user executes a commit command (or=20 rollback).

That seems to work. I think we need to make it more obvious that there's a= =20 transaction in progress - especially as that can be the case after the=20 user hits the Save button and thinks their data is safe (a side-thought=20 is that perhaps we shouldn't require the Save button to be pressed when= =20 auto-commit is turned off, as that's just odd). We should highlight the= =20 transaction state more clearly to the user, and make sure we prompt for=20 confirmation if they try to close the tab or the whole window.
<= /div>

The transaction status can be made more obvious and point out when a=20 transaction is in progress that changes aren't commited. However,=20 removing the save button when auto commit is off will cause us to a send a request and execute a query every time any cell is changed (which can be by accident or some kind of draft). I also think it will make more=20 sense when there is a dedicated button, which can be named such that it=20 is clear that it only executes some queries. Also, the pop up that shows after edits are succeesful can also state thar these changes are not=20 yet commited.

Yeah, I agree=20 removing the button for some modes only is weird. Maybe adding info to=20 the notification, and having a more prominent "Your transaction is sti= ll in progress" notification will be enough.

Will work on adding a notification and m= aking the transaction status more prominent.
=C2=A0

<= div>Another thought - we also need to figure out what happens if the user edits=20 data in the grid and when saving, an error occurs (e.g. trying to insert null into a not-null field). How does that tie into transaction=20 control? For example, auto-rollback may then revert other changes made=20 via SQL (which should have been atomic, with the data changes) - or=20 having auto-rollback turned off may then require the user to explicitly=20 start a new transaction before attempting to save the data again.=20 Perhaps we need to precede data changes with a savepoint, and then roll=20 back to that if there's an error?
I think the savepoint is an adequate solution.If any problems happen then rollback to the savepoint then release it, else just release the=20 savepoint.
=C2=A0
=
I think it makes more sense for filters to be disabled. I mean since the=20 user is already writing SQL it would be more convenient to just edit it=20 directly.

Well we're= =20 not going to just disable them - we'll either remove them, or try to=20 make them work. I'm leaning strongly towards just removing that code=20 entirely.

=C2=A0
I meant disabling them in the query tool while keeping them in the View=20 Data mode as the user cannot edit the sql in the View Data mode. Do you=20 want to remove the feature from both modes completely?

I think you misunderstand - I want = to remove the View Data mode entirely. Your work should replace it.

As a user of pgAdmin I think this might not be the best option. Not all=20 users of pgAdmin are developers or know SQL. I worked on several=20 projects before where other people on the team (or frontend developers)=20 would just want to take a look at some data or do simple edits using the GUI. Also, other management studios for other DBMSs also allow for=20 this. In addition, the user can do sorting of data without knowing SQL.=20 What I think can be done (potentially - maybe in the future) is limit=20 the dependance on SQL knowledge when doing filters in View Data mode,=20 while disabling filters and so in the Query Tool.
<= /div>

+1

View data mode i= s quick & easy way for any novice user who want to interact with table = data.



Hmm, the point of this project (which has been a goal for maybe 20 years!)=20 was to remove that mode entirely. There is an argument that users can=20 use the "SELECT Script" option instead if they don't know SQL= , but that=20 would still require the Sort/Filter options.=C2=A0

What do other folks think?

Waiting for other people's opinion on that matter.

Oh, and icon attached!
=C2=A0
Will work on adding the new icon and switching the save functionality to it. I propose using this icon to save data in both View Data and Query Tool mode, and the existing save button for exclusively saving the query=20 files (will be disabled in View Data mode).

On Wed, Jun 19, 2019= at 4:11 PM Dave Page <dpage@pgadmin.org> wrote:
Hi

On Wed, Jun 19, 2019 at 2:47= PM Yosry Muhammad <yosrym93@gmail.com> wrote:
Hi,


On Wed, Jun 19, 2019, 1:54 PM Dave Page &l= t;dpage@pgadmin.org> wrote:
.
=
- We need to add a "do = you want to continue" warning before actions like Execute or EXPLAIN a= re run, if there are unsaved changes in the grid.

= - I think we should make the text in any cells that has been edited bold un= til saved, so the user can see where changes have been made (as they can wi= th deleted rows).

Both do= ne, new rows are highlighted too.=C2=A0

Nice! I realise it's most likely not your code= , but if you can fix the wrapping so it doesn't break mid-word, that wo= uld be good. See the attached screenshot to see what I mean.
=C2= =A0

<= div dir=3D"auto" style=3D"font-family:sans-serif;font-size:12.8px">Will do.=


- If I make two da= ta edits and then delete a row, I get 3 entries in the History panel, all s= howing the same delete. I would actually argue that data edit queries that = pgAdmin generates should not go into the History at all, but maybe they sho= uld be added albeit with a flag to say they're internal queries and an = option to hide them. Thoughts?

That was a bug with the existing 'save changes' action of = 9;View Data', on which mine is based upon. I fixed the bug, now the que= ries are shown correctly. However, the queries are shown in the form in whi= ch they are sent from the backend to the database driver (without parameter= s - also an already existing bug in View Data Mode), for example:

INSERT INTO public.kweek (
media_url, username, text, created_at) VALUE= S (
%(media_url)s::character varying, %(username)s::character varying, %= (text)s::text, %(created_at)s::timestamp without time zone)
=C2=A0return= ing id;
=C2=A0
I propose two solutions:
1- Hide pgadmin's generated sql from history (in both modes).
2- Show the actual sql query that was executed after the parameter= s are plugged in (more understandable and potentially helpful).

I like the idea of d= oing 2 - but I think we should have a checkbox on the history panel to show= /hide generated queries (and we should include transaction control - BEGIN,= COMMIT etc - in the generated query class).
=C2=A0

I can work on option 2 no= w and then work on=C2=A0
the checkbox if/when there is time.

I'm pretty sure there will be time :-)
=C2=A0


- We need to think about how data editing fits in with transact= ion control. Right now, it seems to happen entirely outside of it - for exa= mple, I tend to work with auto commit turned off, so my connection sits idl= e-in-transaction following an initial select, and remains un-affected by ed= its. Please think about this and suggest options for us to discuss.

I integrated the data editing in= the transaction control as you noted. Now the behavior is as follows:
<= /div>
1- In View Data mode, same existing behavior.
2- In Que= ry Tool mode:
- If auto-commit is on: the modifications are made = and commited once save is pressed.
- If auto-commit is off: the m= odifications are made as part of the ongoing transaction (or a new one if n= o transaction is ongoing), they are not commited unless the user executes a= commit command (or rollback).

That seems to work. I think we need to make it more obvious= that there's a transaction in progress - especially as that can be the= case after the user hits the Save button and thinks their data is safe (a = side-thought is that perhaps we shouldn't require the Save button to be= pressed when auto-commit is turned off, as that's just odd). We should= highlight the transaction state more clearly to the user, and make sure we= prompt for confirmation if they try to close the tab or the whole window.<= /div>

The transact= ion status can be made more obvious and point out when a transaction is in = progress that changes aren't commited. However, removing the save butto= n when auto commit is off will cause us to a send a request and execute a q= uery every time any cell is changed (which can be by accident or some kind = of draft). I also think it will make more sense when there is a dedicated b= utton, which can be named such that it is clear that it only executes some = queries. Also, the pop up that shows after edits are succeesful can also st= ate thar these changes are not yet commited.
<= br>
Yeah, I agree removing the button for some modes only is weir= d. Maybe adding info to the notification, and having a more prominent "= ;Your transaction is still in progress" notification will be enough.

Another thought - we also need to figure out what h= appens if the user edits data in the grid and when saving, an error occurs = (e.g. trying to insert null into a not-null field). How does that tie into = transaction control? For example, auto-rollback may then revert other chang= es made via SQL (which should have been atomic, with the data changes) - or= having auto-rollback turned off may then require the user to explicitly st= art a new transaction before attempting to save the data again. Perhaps we = need to precede data changes with a savepoint, and then roll back to that i= f there's an error?
=C2=A0

=
I think i= t makes more sense for filters to be disabled. I mean since the user is alr= eady writing SQL it would be more convenient to just edit it directly.

Well we're not going to j= ust disable them - we'll either remove them, or try to make them work. = I'm leaning strongly towards just removing that code entirely.

=C2=A0
I meant disablin= g them in the query tool while keeping them in the View Data mode as the us= er cannot edit the sql in the View Data mode. Do you want to remove the fea= ture from both modes completely?

I think you misunderstand - I want to remove the View Dat= a mode entirely. Your work should replace it.
<= /blockquote>

As a user of pgAdmin I think t= his might not be the best option. Not all users of pgAdmin are developers o= r know SQL. I worked on several projects before where other people on the t= eam (or frontend developers) would just want to take a look at some data or= do simple edits using the GUI. Also, other management studios for other DB= MSs also allow for this. In addition, the user can do sorting of data witho= ut knowing SQL. What I think can be done (potentially - maybe in the future= ) is limit the dependance on SQL knowledge when doing filters in View Data = mode, while disabling filters and so in the Query Tool.

Hmm, the point of this project (which has been a g= oal for maybe 20 years!) was to remove that mode entirely. There is an argu= ment that users can use the "SELECT Script" option instead if the= y don't know SQL, but that would still require the Sort/Filter options.= =C2=A0

What do other folks think?

Oh, and icon attached!

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


--
Yosry Muhammad Yosry

Computer = Engineering student,
The Faculty of En= gineering,
Cairo University (2021).
Class representative of CMP 2021.
--000000000000b17f70058bba595a--