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 1tl4EH-0091lB-4n for pgadmin-hackers@arkaria.postgresql.org; Thu, 20 Feb 2025 10:56:29 +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 1tl4EF-004pna-0c for pgadmin-hackers@arkaria.postgresql.org; Thu, 20 Feb 2025 10:56:27 +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 1tl4EE-004pnR-No for pgadmin-hackers@lists.postgresql.org; Thu, 20 Feb 2025 10:56:26 +0000 Received: from mail-oa1-x34.google.com ([2001:4860:4864:20::34]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tl4EB-001wgO-1l for pgadmin-hackers@postgresql.org; Thu, 20 Feb 2025 10:56:25 +0000 Received: by mail-oa1-x34.google.com with SMTP id 586e51a60fabf-2bc66e26179so115311fac.2 for ; Thu, 20 Feb 2025 02:56:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1740048980; x=1740653780; 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=HNccdZ0IBRQYkN9EhBY2z6Dj/3lJipo32vNX60Wfkb4=; b=JLfaRduKRn084M9v9PSwCvRsrksvG4G+K9pT6+1Appo716c1Sz41WLvbYfSQeyDnXU W37ofCbvp7TVL8O561ae71CHAb4iidO+THRcJYREvOLKFWvcb8Cp6c2zdYdMnlHspSOU scGomYKxbdLI4axWDV9XriV9iDQJ7ON6PP/bHa5S878Ewq17FiMZ2PKsaQ9RD9d4gkR8 BDNEPIEE92CTCLAqvwP1SPGx6xqA8uQQluR4/a6EogiGVEjwit1RBF4dQLoDuTCD4Q0R 8MlrQHBuNJsup2WIVEp6sGFca+HPyEDGm8PFBmC7s+h24mfi4J5GTfrxLigar44pyCPh 3kjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740048980; x=1740653780; 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=HNccdZ0IBRQYkN9EhBY2z6Dj/3lJipo32vNX60Wfkb4=; b=bQ40OCjKjdvuWBSBPdEarm8tVtxWWj8UWrq6R+I674AIr9/AO681IC2GhObTqJqjHH 7KMDwPYhcQkbAO843orw8dQuHp63SzefV+PolDzAzJOd0WQjZ1OvgzUADuzwYYIKaWlz LRi06+WZtcF8jk8mQ+Xwsu3Gkr9tJu9aciH99c82Svmieu82/yp/6gzsT+NR0l8EiCsI HIBWsBjnOnD9hKSebNa7WJ1I+IzZTVimi33W1ZyD9dCbKOyfT8wr9ePyhukaoceeakBQ IqA0glgUojIFW0Vb0USMOLyrxTUqcOwZ0i2qyFNs5a9YIkiLWmTXXEL639OlPfZl5G64 i4Qw== X-Forwarded-Encrypted: i=1; AJvYcCUemYNIeOiaMmwe7oy7jzHlM4Js9MlYHfkP+oy8UJ3L5q1I02uvvEXHFnx3M04ibbCflNOn/XfaZ3LqCI/HLWI=@postgresql.org X-Gm-Message-State: AOJu0YyvmKTrCXdkCRzwgpVxoMcZDgELQTDfBOmgnmyvt+meVhxZEQDQ WjzMOTilwfKLEHDxZ4Ql1AwHOhN1T/CUcjdWG1mXHlj1vVUr6k7q4WlgYn0FgNwWpchk917H2oi Xp9q4jYdCSjrwdSlw6sWagdII+pawVlY9/u0d X-Gm-Gg: ASbGnctVJs17Ot8XfqaNrXF5cQfgudt39j8K0oBEierUsHfIMTr1ZKm/sXrkiXeAMao aiFVgCJHYURYwSTnPSlpdX7XzvDfmZFM8CXi5SQvIptQ49sQigwrwaQJ1bxOQHLI2YcKG9Soh3M VY0+SLxKEwOOrG8B02ATA8FsHgqXv1Sag= X-Google-Smtp-Source: AGHT+IG+72rN34/Yo7fr18S4424he6dPHAfQjMEI5M6BvAeF45UbsrmCYSWu0CN5WjFpoBjdUizeCJaYKSE0pXniw9I= X-Received: by 2002:a05:6870:7e01:b0:29f:d0bb:618e with SMTP id 586e51a60fabf-2bc99d4009emr14915540fac.25.1740048980161; Thu, 20 Feb 2025 02:56:20 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Aditya Toshniwal Date: Thu, 20 Feb 2025 16:25:44 +0530 X-Gm-Features: AWEUYZnuHMkFNaVea3T2_F_L7OK9-P0mBSB8FvNG8u2nTHBq1Tgpj16ucTrAu78 Message-ID: Subject: Re: Regarding feature #3319 To: Dave Page Cc: Yogesh Mahajan , Anil Sahoo , pgadmin-hackers Content-Type: multipart/alternative; boundary="0000000000005ad7bc062e90b9e8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000005ad7bc062e90b9e8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dave, On Thu, Feb 20, 2025 at 3:22=E2=80=AFPM Dave Page wrote= : > > > On Thu, 20 Feb 2025 at 03:52, Aditya Toshniwal < > aditya.toshniwal@enterprisedb.com> wrote: > >> Hi Dave, >> >> On Wed, Feb 19, 2025 at 6:55=E2=80=AFPM Dave Page wr= ote: >> >>> >>> >>> 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 = wrote: >>>> >>>>> 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 safe= r 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 differe= nt >>>>> 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 ou= t all >>>>> the session-changing side effects of every query, stored procedure/fu= nction >>>>> 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. Hen= ce >>>> 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 >>> about are those who (for example) have done SET search_path =3D ... and= then >>> performed some destructive operation that worked as expected because of= the >>> earlier SET, but might cause data loss or unexpected consequences if ru= n >>> without the SET. >>> >>> Granted, that class of issues is likely to affect only a small number o= f >>> 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 sessio= ns >> 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 us= ers >> with good performance. >> > > How big do you think the average SQL query/script is? Even in outlier > cases where they might run into a megabyte or two, that's still trivial > compared to what people download browsing Facebook on their phone for > example. > In server mode, the user count may go up. The number of open SQL editor tabs may go up. And there is encryption/decryption that is needed as well. Users changing a browser is also less likely. The feature is most useful for desktop users. > > -- > 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" --0000000000005ad7bc062e90b9e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Dave,

On Th= u, Feb 20, 2025 at 3:22=E2=80=AFPM Dave Page <dpage@pgadmin.org> wrote:

On Thu, 2= 0 Feb 2025 at 03:52, Aditya Toshniwal <aditya.toshniwal@enterprisedb.com= > wrote:
Hi=C2=A0Dave,

<= div dir=3D"ltr" class=3D"gmail_attr">On Wed, Feb 19, 2025 at 6:55=E2=80=AFP= M Dave Page <dpag= e@pgadmin.org> wrote:


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

Hi,

On Wed, Feb 19, 2025 at 5:12=E2=80=AFPM Dave Page <<= a href=3D"mailto:dpage@pgadmin.org" target=3D"_blank">dpage@pgadmin.org= > wrote:
Hi

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

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

Because it stores it at the users machin= e and not on the pgAdmin server, and thus state cannot be restored if the u= ser is on a different machine. I think that's a compelling feature.

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

Or, we make a decision not to bother with that, and to gi= ve=C2=A0the user suitable warnings such as we do when we perform a reconnec= t.

If I understand correctly, Users are com= plaining=C2=A0about losing unsaved data in the query tool and not about dat= a output or session state. Hence just reopening the query tool with only da= ta should be=C2=A0suffice= .

I'm sure tha= t will suffice for 95%+ of users. The ones I'm concerned about are thos= e who (for example) have done SET search_path =3D ... and then performed so= me destructive operation that worked as expected because of the earlier SET= , but might cause data loss or unexpected consequences if run without the S= ET.

Granted, that class of issues is likely to aff= ect only a small number of users in reality, but the consequences could eas= ily be data loss.

It may be compelling to restore your wo= rkspace 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 re= quire 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.=

How big do you thi= nk the average SQL query/script is? Even in outlier cases where they might = run into a megabyte or two, that's still trivial compared to what peopl= e download browsing Facebook on their phone for example.
<= /blockquote>
In server mode, the user count may go up.=C2=A0The number o= f open SQL editor tabs may go up. And there is encryption/decryption that i= s needed as well. Users changing a browser is also less likely. The feature is most useful for d= esktop users.
=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"
--0000000000005ad7bc062e90b9e8--