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 1tkk4t-006Qdc-Hx for pgadmin-hackers@arkaria.postgresql.org; Wed, 19 Feb 2025 13:25:27 +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 1tkk4s-008Si4-2O for pgadmin-hackers@arkaria.postgresql.org; Wed, 19 Feb 2025 13:25:26 +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 1tkk4r-008Shw-Pz for pgadmin-hackers@lists.postgresql.org; Wed, 19 Feb 2025 13:25:26 +0000 Received: from mail-lf1-x130.google.com ([2a00:1450:4864:20::130]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tkk4p-001lZH-01 for pgadmin-hackers@postgresql.org; Wed, 19 Feb 2025 13:25:25 +0000 Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-5461b5281bcso3475682e87.3 for ; Wed, 19 Feb 2025 05:25:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin.org; s=google; t=1739971522; x=1740576322; 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=OD2ODehp7NQXMfkaBWA0BysVRs0bfmNOZg3bqfhH4vE=; b=FtCFYIyHLh+0CAc2qV5LykJTdngAywPDj5VngHZAqyDmTfcLTc0fsW9Y8zDDeA6lN2 fzOPpvyx6U0KS4MKyJqvUjI+i3iXR8PPsd2oA+8RN5BfSkFcVmX0kRDHv7uWuHhGXU3v VBOPgriUsRXzOtIUBRT8W6xkPwAiHBUfDpsxTlWpwnGWRxcriAlNGY9Orwhx9kSDaswM KtYKUw+xp9t9ZyeJWgnT9o9eU/NViBfOpYUYbJ6HGPXz2MGIWv0c4mVsbwJ29aEagLSz 56+GOAUIWYB/FwbtH+LRmnYQ0brc46r++JI5CJjgDJSRxWTNVqHni5f3VZ7u4tYN6G0a DvvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739971522; x=1740576322; 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=OD2ODehp7NQXMfkaBWA0BysVRs0bfmNOZg3bqfhH4vE=; b=ovhTOQYXmpsNJ1zTAnGaLBgCZmwRErQrT1+gBbbk3Tg+Nl8HqcEfdLZH+nQ/Mkd9/d 0nC2M/gkmoESOKNQfWARB2m1tXmkY23PyegYHD6JlHOSyT2hwiEC+S5UNiBtnIGboAG/ q+FrTFZrYI6n7RCjbjWEybehcmYRJjfpDT08KX6sCu/sahYCN8VWOCfVj8x2N5I1qag1 QmBfVqzVg956olLTFF5XGzZ9VK6l4SOVAw2ri3Him3TLfbzvSrpveJAYarfNf8u1X7lt RlVNFfi6MxlTgTwnBud4ZSNBLwKLQvMDdLKkGcT3Bs8l9MdF3uVxS/h5fXyy6dEcQBX6 CkcA== X-Forwarded-Encrypted: i=1; AJvYcCUhWYA3zcZ9KvZBdt3DXTfHnQdgyxwzvg00ZsN1qTx+EYO/89ArpS1ueok7kyO9WlECDh5EKCeaifo2HGvaz7I=@postgresql.org X-Gm-Message-State: AOJu0YxF8+BJ/caHBZf3J633V3oR/fSLe2W7WqepSYSqnY06LuiY4JZK 8RJsb73kedHI2E3iyGS4RfN8GijL9WpHsT30yMWwJbpIcz6jKAo7eca+vFgOssppTITlGLHy5dV T6fuzOjoxXtriO1Otd2rCqUjuN26f9PZB2m5gJNIXUr7MMFdYsA== X-Gm-Gg: ASbGncsbu+nzGTxAM9mA7vl8wD4Ezl/I7iwjtsNQtkx0f5/NMDXYQsKIebwf3FyQxIK RYVDqE5EnLa/7t5bjwATzHIB0XetsHCT8cFnB+At7x8oJSh0aKguj3RJ2y54Z8buytlhpRE7DDk E= X-Google-Smtp-Source: AGHT+IFsu+V77LsRExyzoKKzPWgmXXMPrvK7tOwiDGpAXXMuApD0gOkXI0FuhlprVhy41cDydaZEYK0y9Uh7kqvCZ7U= X-Received: by 2002:a05:6512:108a:b0:545:b5e:2c0 with SMTP id 2adb3069b0e04-5452fe42a69mr7667090e87.15.1739971521703; Wed, 19 Feb 2025 05:25:21 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dave Page Date: Wed, 19 Feb 2025 13:25:10 +0000 X-Gm-Features: AWEUYZkP49KGSUouqj-itCs4T3AVfRkRKfBukaqab9BZk6Nl8cul4GgpjPwBAtQ Message-ID: Subject: Re: Regarding feature #3319 To: Yogesh Mahajan Cc: Aditya Toshniwal , Anil Sahoo , pgadmin-hackers Content-Type: multipart/alternative; boundary="0000000000007899ee062e7eb064" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000007899ee062e7eb064 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wro= te: > >> 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 t= o >>> 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 a= ll >> the session-changing side effects of every query, stored procedure/funct= ion >> 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 dat= a > 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 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. --=20 Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org pgEdge: https://www.pgedge.com --0000000000007899ee062e7eb064 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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 <= adit= ya.toshniwal@enterprisedb.com> wrote:
Hi=C2=A0Anil/Dav= e,

Why not use browser localStorage for sa= ving 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.= =C2=A0
For Electron also= it should work.
This wi= ll reduce load on the pgAdmin server.

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

That s= aid, I think this is largely irrelevant until the fundamental problem is so= lved. e.g. how do we restore the state of the session (spoiler: it's al= most certainly not possible, unless we can figure out all the session-chang= ing side effects of every query, stored procedure/function etc. that may ha= ve been directly or indirectly called).

Or, we mak= e a decision not to bother with that, and to give=C2=A0the user suitable wa= rnings such as we do when we perform a reconnect.

If I understand correctly, Users are complaining=C2=A0about losing u= nsaved data in the query tool and not about data output or session state. H= ence just reopening the query tool with only data should be=C2=A0suffice.

I'm sure that will suffice for 95%+ of u= sers. The ones I'm concerned about are those who (for example) have don= e SET search_path =3D ... and then performed some destructive operation tha= t 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 u= sers in reality, but the consequences could easily be data loss.
= =C2=A0
--
--0000000000007899ee062e7eb064--