Re: Regarding feature #3319

Hi Dave,

On Thu, Feb 20, 2025 at 3:22 PM Dave Page <dpage(at)pgadmin(dot)org> wrote:

>
>
> 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.
>
In server mode, the user count may go up. The number of open SQL editor
tabs may go up. And there is encryption/decryption that is needed as well.
Users changing a browser is also less likely. The feature is most useful
for desktop users.

>
> --
> Dave Page
> pgAdmin: https://www.pgadmin.org
> PostgreSQL: https://www.postgresql.org
> pgEdge: https://www.pgedge.com
>
>

--
Thanks,
Aditya Toshniwal
pgAdmin Hacker | Sr. Staff SDE II | *enterprisedb.com*
<https://www.enterprisedb.com/>
"Don't Complain about Heat, Plant a TREE"