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 1hdhXR-0007sT-Nz for pgadmin-hackers@arkaria.postgresql.org; Wed, 19 Jun 2019 20:50:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hdhXQ-0006Ws-EO for pgadmin-hackers@arkaria.postgresql.org; Wed, 19 Jun 2019 20:50:36 +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 1hdhWt-0003rx-SQ for pgadmin-hackers@lists.postgresql.org; Wed, 19 Jun 2019 20:50:04 +0000 Received: from mail-qt1-x82f.google.com ([2607:f8b0:4864:20::82f]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hdhWp-0000Jf-1Q for pgadmin-hackers@postgresql.org; Wed, 19 Jun 2019 20:50:02 +0000 Received: by mail-qt1-x82f.google.com with SMTP id d17so704751qtj.8 for ; Wed, 19 Jun 2019 13:49:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Sfes8j1OLa92Ma6kvDoJF2YL/zMILIiVKGivES97TKk=; b=Qz39Btr+S4kn/R0X5mGYbnB6rY9jVTBKLME59Lw6mxVxuSo9hHePYoCUDoyZd4zJE0 HiknMa8fUTeQ1inoQuuCvUTRj1kzjDmcOmFKT/0xnZDgKXq1yYvvr4XlZ+TWjAomtea3 vJIP34bW8njTG+3Xqi3nVYgQBO3hMqVX5NroS6UjhLEOJoLZsHAic3DrmgTFSQLOGxgH Sg+B3Wh5aGFs0NGaOJ3tglYp0G5JATCKi4D4FsPYxwQwnM/fxTrJPNlbfrlxbVjYjWqw zY0TK/Khfz63BClSC1/jKpT7vtaZvqVyFjJDjDuezgDfdoIXhYJ0mDB4hUR05W6zgHc2 CdWQ== 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; bh=Sfes8j1OLa92Ma6kvDoJF2YL/zMILIiVKGivES97TKk=; b=Q9uzYt3W052gC+9MJdDqUvs1ECAO6pKc/qD+esjS0db7CTsq2j6xbdMFDlzxXWLBLX pJlqxTUpOF6bXKjdFy1zC7qrBOgR2nEAdR5D0FjJeSfNfGHpi1xSar3kq4g1kkn4K2Ek VFAGmoHPDbQ10G1bqq2wbQ9vCo0xmOd6VEAvvRoMJcKGGKZla19sUDocOJ2JmFi2DiRL 2AhfsGb+kxIvrD88Ew/3WE7XaKEA2q3gt8F7wY22j0ycMpI6ozzQoFv1aDQlVRiHoy8H tJf9XX8CcqM99NXgBHf7r/aYayJIEpC7BYx7zRV7BaHydGzJZXcUR9fKJD80Itff3XTZ TbFA== X-Gm-Message-State: APjAAAVsozziqFAZkvGBMk+8S7zj628Z72PJqmr9mcl7PX4ibLOYikzZ PzaUwgU3/C7ybnbNtZL4m0N3gVR711FHpcgrcXw= X-Google-Smtp-Source: APXvYqwxHdIe4IN27dYGpJMo+R2hs+dfOR4InyK9KrKIJnqd6d08Z7qmVk6hge9zBXIntWLbeBihzj9RM7YZZOXHqpY= X-Received: by 2002:aed:37a1:: with SMTP id j30mr10892875qtb.367.1560977397926; Wed, 19 Jun 2019 13:49:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yosry Muhammad Date: Wed, 19 Jun 2019 22:49:45 +0200 Message-ID: Subject: Re: [GSoC][Patch] Automatic Mode Detection V1 To: Dave Page , pgadmin-hackers@postgresql.org Content-Type: multipart/alternative; boundary="0000000000004e4cf1058bb35f80" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --0000000000004e4cf1058bb35f80 Content-Type: text/plain; charset="UTF-8" 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. >> > > 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/ --0000000000004e4cf1058bb35f80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi 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

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
<= div style=3D"color:purple;font-family:sans-serif;font-size:12.8px" dir=3D"a= uto">
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>
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@pgadmi= n.org> wrote:
Hi

On Wed, Jun 19, 2019 at 2:47 PM Yosry Muhamma= d <yosrym93@gmai= l.com> wrote:
Hi,


On Wed, Ju= n 19, 2019, 1:54 PM Dave Page <dpa= ge@pgadmin.org> wrote:
.
- We need to add a "do you want to continue" warning before act= ions like Execute or EXPLAIN are run, if there are unsaved changes in the g= rid.

- I think we should make the text in any cell= s 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.=C2=A0

Nice! I realise it&#= 39;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 s= ee what I mean.
=C2=A0

Will do.


- If I make two dat= a edits and then delete a row, I get 3 entries in the History panel, all sh= owing the same delete. I would actually argue that data edit queries that p= gAdmin generates should not go into the History at all, but maybe they shou= ld be added albeit with a flag to say they're internal queries and an o= ption 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 quer= ies are shown correctly. However, the queries are shown in the form in whic= h 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)
=C2=A0returni= ng 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 parameters= are plugged in (more understandable and potentially helpful).

I like the idea of do= ing 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 now= 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 transaction control. Right now, it see= ms 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 a= nd suggest options for us to discuss.
I integrated the data editing in the transaction control as yo= u noted. Now the behavior is as follows:
1- In View Data mode= , same existing behavior.
2- In Query Tool mode:
- If a= uto-commit is on: the modifications are made and commited once save is pres= sed.
- If auto-commit is off: the modifications are made as part = of the ongoing transaction (or a new one if no transaction is ongoing), the= y 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 transactio= n 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 w= e shouldn't require the Save button to be pressed when auto-commit is t= urned off, as that's just odd). We should highlight the transaction sta= te more clearly to the user, and make sure we prompt for confirmation if th= ey try to close the tab or the whole window.
=

The transaction status can be made more ob= vious 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 ch= anged (which can be by accident or some kind of draft). I also think it wil= l 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 re= moving the button for some modes only is weird. Maybe adding info to the no= tification, and having a more prominent "Your transaction is still in = progress" notification will be enough.

Anothe= r 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 in= to a not-null field). How does that tie into transaction control? For examp= le, auto-rollback may then revert other changes made via SQL (which should = have been atomic, with the data changes) - or having auto-rollback turned o= ff may then require the user to explicitly start a new transaction before a= ttempting to save the data again. Perhaps we need to precede data changes w= ith a savepoint, and then roll back to that if there's an error?
<= div>=C2=A0

=
I think it makes m= ore sense for filters to be disabled. I mean since the user is already writ= ing SQL it would be more convenient to just edit it directly.

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

=C2=A0
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 en= tirely. 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 SQ= L. I worked on several projects before where other people on the team (or f= rontend developers) would just want to take a look at some data or do simpl= e 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 knowin= g SQL. What I think can be done (potentially - maybe in the future) is limi= t the dependance on SQL knowledge when doing filters in View Data mode, whi= le disabling filters and so in the Query Tool.

Hmm, the point of this project (which has been a goal for m= aybe 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.=C2=A0

What do other folks think?

Oh, and icon attached!

--
Dave Page
Blog: http://pgsnake.blog= spot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.comThe Enterprise PostgreSQL Company


--
Yosry= Muhammad Yosry

<= /i>
Computer Engineering student,
=
The Faculty of Engineering,
Cairo University (2021).
Class representative of CMP 2021.
--0000000000004e4cf1058bb35f80--