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 1tl3Du-008tyj-Oi for pgadmin-hackers@arkaria.postgresql.org; Thu, 20 Feb 2025 09:52:03 +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 1tl3Ds-0042pP-DI for pgadmin-hackers@arkaria.postgresql.org; Thu, 20 Feb 2025 09:52:00 +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 1tl3Ds-0042pG-4z for pgadmin-hackers@lists.postgresql.org; Thu, 20 Feb 2025 09:52:00 +0000 Received: from mail-lj1-x230.google.com ([2a00:1450:4864:20::230]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tl3Dp-001wAW-1p for pgadmin-hackers@postgresql.org; Thu, 20 Feb 2025 09:51:59 +0000 Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-30918c29da2so7170071fa.0 for ; Thu, 20 Feb 2025 01:51:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin.org; s=google; t=1740045116; x=1740649916; 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=83QFoETZABDwQZFu4SwAOT8UmiO78ZepKXBvGrQmFfw=; b=lKWfaNdGEebJul7HSa+ENhs9GlTIEKJeltMkX3DiiiIvwocKmMxt0HvC4wngMg0AhV lrV8sEQGVXQVQ/ceLtoy2eE+/zOmKJXVyYL345JG3ZqljAF2IwTcScmUDFllWQslj4pC WTULIad6+NL0jLEHlu4w8OHap/EoUp90DQ6euwno3968qh4+/n/4aLUK/gLe+FEPOvJs sfNbXUmuyC9qsqnuMfwPk5PubnQqIvTrL1n/jn98d4d4XKyHeFMgnajC2HmVsG5nxKsH PKMH1kis4aQkcaDVIfiX0OrZzdI3yiOst5rIsTLenPOuL3AYEViDUmW2BSmtdEr3JJSV OGEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740045116; x=1740649916; 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=83QFoETZABDwQZFu4SwAOT8UmiO78ZepKXBvGrQmFfw=; b=buNGvWFSbJPZhexVbxvHC0qq+VtZsczBhY1bbh2apF1vFrM2Wkg3LUaLrDVw87/3W2 wBsjXG9Sgq/ZKsLXFFwDvhsTt2Y2UIA9ca+MhFLk1gLFz/mDm7gm2aBUVW4Eg53IMLIZ Iz5Pd9IU2HEik5uuJLHHDoElYoW5eVaVd+YBahQknLrNiS9oZyPk1fdtDf8OfWVyuJPD 1PkV2fSUipHaxFjctgd7EBjGqxMODH/d0FbWhf/nSv6fOoscsVxfyOGASSN89HGsbMXA HG2ZiUe0n9g6FztLvh7Sx9oTMjll0F5761dtJuA1VuFxHoJsEWhkNPEpHKfG6NnZumCR Dzdw== X-Forwarded-Encrypted: i=1; AJvYcCUOxz0V1bZHaw7/nZx055bkX8+FyeseRnctEGejUUkQlxNKPvxoLlgicPpRLCcSglZwAas7JtFq3RvEWplZRaw=@postgresql.org X-Gm-Message-State: AOJu0YxsJ3p4NORACYCqDyyx0ky82J0Go0+JP3agHheID//g4H5YckkU ClwuNQelUtpQfYMLv4atxeLbfOqWL4pwIfgkt7duAQmM8llOgHbkF0IPwTcU8ONklbdloXmNH2c CFBA45XInoJgSQp4qJXediVUUhDZzO7s+X/K/ X-Gm-Gg: ASbGncs+Wrs/72GV9X9F4Dnsc8Hv1slOtwBC2YYFa9eWSXI90uxQp/xwlwqUNxktsfW LibrMOSZzPNxd2OzQdxyxjY3GRROwkl3a9utCRWBcoT1RZFo4TUeTgChOjEmhP61ypXy+WMt+DZ o= X-Google-Smtp-Source: AGHT+IF45EO1IfnAqZD+up7RU+k/sMI0rHsl7gmF4rC363a+SOCG+EmE7W7kxSfwJVEFnjUi36sIwO9Z/z6sTGQo9zM= X-Received: by 2002:a05:6512:158f:b0:545:54b:6a05 with SMTP id 2adb3069b0e04-5452fe93328mr8242306e87.45.1740045116099; Thu, 20 Feb 2025 01:51:56 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dave Page Date: Thu, 20 Feb 2025 09:51:44 +0000 X-Gm-Features: AWEUYZmCdhEn1UsL0dDrz75CzcgmrIKZEhR9neDGs4fzICz_lSrhHuDWsTAGoIg Message-ID: Subject: Re: Regarding feature #3319 To: Aditya Toshniwal Cc: Yogesh Mahajan , Anil Sahoo , pgadmin-hackers Content-Type: multipart/alternative; boundary="00000000000009ebad062e8fd398" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000009ebad062e8fd398 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wro= te: > >> >> >> 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 w= rote: >>> >>>> 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 differen= t >>>> 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/fun= ction >>>> 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. Henc= e >>> 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 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 worl= d > 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 > 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 use= rs > 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. --=20 Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org pgEdge: https://www.pgedge.com --00000000000009ebad062e8fd398 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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

On Wed, Feb 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:= 12=E2=80=AFPM Dave Page <dpage@pgadmin.org> wrote:
Hi

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

Why not use browser localStorage for saving thi= s 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.=C2=A0
For Electron also it shou= ld work.
This will reduc= e load on the pgAdmin server.

B= ecause 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 thi= nk that's a compelling feature.

That said, I t= hink 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 cer= tainly 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 deci= sion not to bother with that, and to give=C2=A0the user suitable warnings s= uch as we do when we perform a reconnect.

I= f I understand correctly, Users are complaining=C2=A0about losing unsaved d= ata in the query tool and not about data output or session state. Hence jus= t reopening the query tool with only data should be=C2=A0suffice.

I'm sure that will suffice for 95%+ of users. Th= e ones I'm concerned about are those who (for example) have done SET se= arch_path =3D ... and then performed some destructive operation that worked= as expected because of the earlier SET, but might cause data loss or unexp= ected 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.
<= /blockquote>

It= may be compelling to restore your workspace on any browser in the world bu= t is it worth it? I mean think about the overhead it will put on the pgAdmi= n server. Plus the storage it will require on the server side. Already peop= le are asking to make pgAdmin storage free by putting sessions in db instea= d 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&#= 39;ll have an advantage of storing on the client side and it will cover mos= t of the users with good performance.
<= div>
How big do you think the average SQL query/script is? Ev= en 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.
=C2=A0
--
--00000000000009ebad062e8fd398--