Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tkxcP-0089yR-37 for pgadmin-hackers@arkaria.postgresql.org; Thu, 20 Feb 2025 03:52:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tkxcM-000DvY-0Q for pgadmin-hackers@arkaria.postgresql.org; Thu, 20 Feb 2025 03:52:54 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tkxcL-000DuB-NC for pgadmin-hackers@lists.postgresql.org; Thu, 20 Feb 2025 03:52:53 +0000 Received: from mail-oo1-xc35.google.com ([2607:f8b0:4864:20::c35]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tkxcI-001tI1-0N for pgadmin-hackers@postgresql.org; Thu, 20 Feb 2025 03:52:52 +0000 Received: by mail-oo1-xc35.google.com with SMTP id 006d021491bc7-5fcd665af4eso147921eaf.2 for ; Wed, 19 Feb 2025 19:52:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1740023567; x=1740628367; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hzp5j6kMotFL2rSN1mnv8b5ZSkIOVgABmk5SxaAyQAo=; b=W03iwXcLfi39LVHXXCrUEUq2I2yHLjkickSkDMRjMMcmGRMd50m8FOY6iTlL/1v0YU OI/CI+7VxiWA0qj4oPnW7pIdQvxQ7W6jtRrrhpQNrT5wsO4HCTDfxflVwzRjHFN9uUzI GWcRcudUWw1vH5aEoNtaOdvQnkJpsRQ9x+HW/afQu+TGExl5QOcd9CVtefW/wn9tE7G0 y6Z2PfT7W3SI8LRIdCPi8r/SO8Aso1vkMBz4lAlOPfSE4uAFyvAkncOwrSshnHSe/3W0 uDOH4y5qq+rbA2H/ZBp+2zuc3zPZT36Jip6z5up/bNO2CLBdEctFXdOwgBmR7HpqtAJN ZChA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740023567; x=1740628367; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hzp5j6kMotFL2rSN1mnv8b5ZSkIOVgABmk5SxaAyQAo=; b=tHRTqfViSEy1Hd43l3RN9DgLWh1TlC8j+00Kx1H+2/qQSaMbdpl/5hO1OkOtqHgQUS AmCiAJmU6hyb64VAXA6ND41XViPsK445oX61VA1Tp0Tondfht2ZSRiD9jIdZXmdAMyLg bqb+nR/+Tmwxfi0zZ6x/fJUqvoiq8bSoMIm83ff/RwSr3Eh4HSowzUTmZs7X2ijSGruL 2gSuAFZnjYrRAD3uaNSXpUKR1WEOeNxpw8LHQOyIt8pTuSYPJzGzRyvdn1qkDlQG7Zwn u/FceCXOcql70XfLnoLJB59+/Ek7dgZf9gfziB3+9apALAOO7HLp7vTPRVIuifTIKjgx WdxQ== X-Forwarded-Encrypted: i=1; AJvYcCWhBvMrTr3hMTZBq/w0sqphQZ8fQOyWEFxi2RaURT1JVXkrfRTFFEAKsNCsADeTmC4UOSd168jUGNT/fRKr71M=@postgresql.org X-Gm-Message-State: AOJu0Yzg+XLxd5/dnOypLdBkjIYtnkZ5/d4BsqDnAbQzEWntChSGohAY 602KBADr3ZmPb8WOqeA9LJECJgUjiO1o5CWN82zxnlGuhFlTel9u18hn6c+MOcSH5mb+5my3Rk+ /gYEJy2uCGFm1Hw3ULis7xcRC8ZvukKyKN3PL X-Gm-Gg: ASbGncuyezdw0CVvbpedd1xpms3zj8HExKcaypiC7DJ1p2CmWhkDjIIn4QyaSbM+yoQ FLMCrLvQ1iGIYMUaBtFrtkDSDa3RShazlubfik3eohCrlfmhvWD4w61sF7oSluzQuISA2L7Nvll 6MXl9DZD0FNYZDg9kL87OqmkXyr51/n3o= X-Google-Smtp-Source: AGHT+IG84WSnm2nhs1cwiuX8UuG0qP3rnSXIAQElrSJYiMJOkPeYTwZb+CGnTwb8f2qHhjTScVaZCbBclv4rXET7PE4= X-Received: by 2002:a05:6871:4b88:b0:2bb:15b1:55b4 with SMTP id 586e51a60fabf-2bc99d673demr13739793fac.31.1740023567452; Wed, 19 Feb 2025 19:52:47 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Aditya Toshniwal Date: Thu, 20 Feb 2025 09:22:11 +0530 X-Gm-Features: AWEUYZlzVj36GA3lRL6SyxqNDFpzkPR2q5Dz3T1fwB3hrAfn4y23dpvgTFYvzxc Message-ID: Subject: Re: Regarding feature #3319 To: Dave Page Cc: Yogesh Mahajan , Anil Sahoo , pgadmin-hackers Content-Type: multipart/alternative; boundary="000000000000a3a8c4062e8ace68" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000a3a8c4062e8ace68 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dave, On Wed, Feb 19, 2025 at 6:55=E2=80=AFPM Dave Page wrote= : > > > On Wed, 19 Feb 2025 at 12:24, Yogesh Mahajan < > yogesh.mahajan@enterprisedb.com> wrote: > >> >> Hi, >> >> On Wed, Feb 19, 2025 at 5:12=E2=80=AFPM Dave Page wr= ote: >> >>> Hi >>> >>> On Thu, 16 Jan 2025 at 06:37, Aditya Toshniwal < >>> aditya.toshniwal@enterprisedb.com> wrote: >>> >>>> Hi Anil/Dave, >>>> >>>> Why not use browser localStorage for saving this information? It >>>> persists when the browser closes and is based on the URL. It is safer = to >>>> store at the user's machine than on our server. >>>> For Electron also it should work. >>>> This will reduce load on the pgAdmin server. >>>> >>> >>> Because it stores it at the users machine and not on the pgAdmin server= , >>> and thus state cannot be restored if the user is on a different machine= . I >>> think that's a compelling feature. >>> >>> That said, I think this is largely irrelevant until the fundamental >>> problem is solved. e.g. how do we restore the state of the session >>> (spoiler: it's almost certainly not possible, unless we can figure out = all >>> the session-changing side effects of every query, stored procedure/func= tion >>> etc. that may have been directly or indirectly called). >>> >>> Or, we make a decision not to bother with that, and to give the user >>> suitable warnings such as we do when we perform a reconnect. >>> >> >> If I understand correctly, Users are complaining about losing unsaved >> data in the query tool and not about data output or session state. Hence >> just reopening the query tool with only data should be suffice. >> > > I'm sure that will suffice for 95%+ of users. The ones I'm concerned abou= t > are those who (for example) have done SET search_path =3D ... and then > performed some destructive operation that worked as expected because of t= he > earlier SET, but might cause data loss or unexpected consequences if run > without the SET. > > Granted, that class of issues is likely to affect only a small number of > users in reality, but the consequences could easily be data loss. > It may be compelling to restore your workspace on any browser in the world but is it worth it? I mean think about the overhead it will put on the pgAdmin server. Plus the storage it will require on the server side. Already people are asking to make pgAdmin storage free by putting sessions in db instead of file based and so on. Also, the information cannot be saved as is, it needs to be encrypted (more overhead). On a slower internet, restoring might take a long time. We'll have an advantage of storing on the client side and it will cover most of the users with good performance. > > -- > Dave Page > pgAdmin: https://www.pgadmin.org > PostgreSQL: https://www.postgresql.org > pgEdge: https://www.pgedge.com > > --=20 Thanks, Aditya Toshniwal pgAdmin Hacker | Sr. Staff SDE II | *enterprisedb.com* "Don't Complain about Heat, Plant a TREE" --000000000000a3a8c4062e8ace68 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Dave,

=
On Wed, Fe= b 19, 2025 at 6:55=E2=80=AFPM Dave Page <dpage@pgadmin.org> wrote:
=

On Wed, 19 Feb 2025 at 12:24, Yogesh Mahajan <yogesh.mahajan@enterprisedb.= com> wrote:

Hi,

On Wed, Feb 19, 2025 at 5:1= 2=E2=80=AFPM Dave Page <dpage@pgadmin.org> wrote:
Hi

On Thu, 16 Jan 2025 at 06:3= 7, Aditya Toshniwal <aditya.toshniwal@enterprisedb.com> wrote:
Hi=C2=A0Anil/Dave,

Why not use browser localStorage for saving this informati= on? It persists when the browser closes and is based on the URL. It is safe= r to store at the user's machine than on our server.=C2=A0
For Electron also it should work.
This will reduce load on t= he pgAdmin server.

Because it s= tores it at the users machine and not on the pgAdmin server, and thus state= cannot be restored if the user is on a different machine. I think that'= ;s a compelling feature.

That said, I think this i= s largely irrelevant until the fundamental problem is solved. e.g. how do w= e restore the state of the session (spoiler: it's almost certainly not = possible, unless we can figure out all the session-changing side effects of= every query, stored procedure/function etc. that may have been directly or= indirectly called).

Or, we make a decision not to= bother with that, and to give=C2=A0the user suitable warnings such as we d= o when we perform a reconnect.

If I underst= and correctly, Users are complaining=C2=A0about losing unsaved data in the = query tool and not about data output or session state. Hence just reopening= the query tool with only data should be=C2=A0suffice.
I'm sure that will suffice for 95%+ of users. The ones I&#= 39;m concerned about are those who (for example) have done SET search_path = =3D ... and then performed some destructive operation that worked as expect= ed because of the earlier SET, but might cause data loss or unexpected cons= equences if run without the SET.

Granted, that cla= ss of issues is likely to affect only a small number of users in reality, b= ut the consequences could easily be data loss.

It may be compelling to restore your workspace on any browser i= n the world but is it worth it? I mean think about the overhead it will put= on the pgAdmin server. Plus the storage it will require on the server side= . Already people are asking to make pgAdmin storage free by putting session= s in db instead of file based and so on. Also, the information cannot be sa= ved as is, it needs to be encrypted (more overhead).
On a slower internet, = restoring might take a long time. We'll have an advantage of storing on= the client side and it will cover most of the users with good performance.=
=C2=A0
--


--
Thanks,
Aditya Toshniw= al
pgAdmin Hacker=C2=A0| Sr. Staff SDE II=C2= =A0| enterprisedb.com
"Don't Complain about Heat, Plant a TREE"
--000000000000a3a8c4062e8ace68--