Re: Regarding feature #3319

On Thu, 20 Feb 2025 at 03:52, Aditya Toshniwal <
aditya(dot)toshniwal(at)enterprisedb(dot)com> wrote:

> Hi Dave,
>
> On Wed, Feb 19, 2025 at 6:55 PM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
>>
>>
>> On Wed, 19 Feb 2025 at 12:24, Yogesh Mahajan <
>> yogesh(dot)mahajan(at)enterprisedb(dot)com> wrote:
>>
>>>
>>> Hi,
>>>
>>> On Wed, Feb 19, 2025 at 5:12 PM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>>
>>>> Hi
>>>>
>>>> On Thu, 16 Jan 2025 at 06:37, Aditya Toshniwal <
>>>> aditya(dot)toshniwal(at)enterprisedb(dot)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 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