public inbox for [email protected]
help / color / mirror / Atom feedFrom: Dave Page <[email protected]>
To: Aditya Toshniwal <[email protected]>
Cc: Yogesh Mahajan <[email protected]>
Cc: Anil Sahoo <[email protected]>
Cc: pgadmin-hackers <[email protected]>
Subject: Re: Regarding feature #3319
Date: Thu, 20 Feb 2025 09:51:44 +0000
Message-ID: <CA+OCxozGMt+GjOSn7XZ24mfde+=vAXvNYtJEJ8WR6=fda-LP=g@mail.gmail.com> (raw)
In-Reply-To: <CAM9w-_=aB30i4Ev=Xj_jR1ysB+y_yNRXsLC2-3fJ1fd6f2CRDg@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>
<CA+OCxoyXBn+heMWc7Jg_b+sB=+KnTwcwGBYj2Tx8bzSNNqV8Uw@mail.gmail.com>
<CAM9w-_=aB30i4Ev=Xj_jR1ysB+y_yNRXsLC2-3fJ1fd6f2CRDg@mail.gmail.com>
On Thu, 20 Feb 2025 at 03:52, Aditya Toshniwal <
[email protected]> wrote:
> Hi Dave,
>
> On Wed, Feb 19, 2025 at 6:55 PM Dave Page <[email protected]> wrote:
>
>>
>>
>> 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.
>>
>
> 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.
>
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.
--
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+OCxozGMt+GjOSn7XZ24mfde+=vAXvNYtJEJ8WR6=fda-LP=g@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