public inbox for [email protected]
help / color / mirror / Atom feedFrom: Dave Page <[email protected]>
To: Yogesh Mahajan <[email protected]>
Cc: Aditya Toshniwal <[email protected]>
Cc: Anil Sahoo <[email protected]>
Cc: pgadmin-hackers <[email protected]>
Subject: Re: Regarding feature #3319
Date: Wed, 19 Feb 2025 13:25:10 +0000
Message-ID: <CA+OCxoyXBn+heMWc7Jg_b+sB=+KnTwcwGBYj2Tx8bzSNNqV8Uw@mail.gmail.com> (raw)
In-Reply-To: <CAMa=N=PGM2e3k0Vs7P_0O2sgsvU5HO2PgJVF6jWDarjvE2EXQA@mail.gmail.com>
References: <CAO+oWtC0aHG_7D69OiHvjHfpt9fJt=Q0LhPu_2oLCD71c1QORw@mail.gmail.com>
<CA+OCxoz=3WbRzir+sP9qba97Tn4YrRV0bq5CFcVNtFsNKZ+5Lw@mail.gmail.com>
<CAO+oWtAS2D3G_+rTOn2iY0HJLkJMjr2D6WNui+X8jZ_CSGiT_w@mail.gmail.com>
<CAM9w-_=Y4ht5P9-PeDz++Sk5EAKU9jKkvTTNBU+mQEzWo0BoPw@mail.gmail.com>
<CAO+oWtDjAydE7p8XSj4pW3WnXtgdoB+vQxC5AxsfdTsaVBRwbw@mail.gmail.com>
<CAM9w-_n-Uh=rvV6CTESUnoiiUaUa2vxao7SJBVrrv1E0uMWRpQ@mail.gmail.com>
<CAO+oWtCjn=0QCdXU1eXUk_zGqEn_qWQDAmoOadNkZwiUT58Jfg@mail.gmail.com>
<CAM9w-_=42-JBrLX=-SB_6GyWC7PO1-T8MhvYn5r0aQcyZ+xt0w@mail.gmail.com>
<CA+OCxozyK0z=UF+V1ypLxh0kJxW=NsgEObKSiJ-CZGdRfH5_Tw@mail.gmail.com>
<CAMa=N=PGM2e3k0Vs7P_0O2sgsvU5HO2PgJVF6jWDarjvE2EXQA@mail.gmail.com>
On Wed, 19 Feb 2025 at 12:24, Yogesh Mahajan <
[email protected]> wrote:
>
> Hi,
>
> On Wed, Feb 19, 2025 at 5:12 PM Dave Page <[email protected]> wrote:
>
>> Hi
>>
>> On Thu, 16 Jan 2025 at 06:37, Aditya Toshniwal <
>> [email protected]> 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/function
>> 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 about
are those who (for example) have done SET search_path = ... 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.
--
Dave Page
pgAdmin: https://www.pgadmin.org
PostgreSQL: https://www.postgresql.org
pgEdge: https://www.pgedge.com
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Regarding feature #3319
In-Reply-To: <CA+OCxoyXBn+heMWc7Jg_b+sB=+KnTwcwGBYj2Tx8bzSNNqV8Uw@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox