Re: Regarding feature #3319

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

> 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.
>

Sure. Until you get to 100's or 1000's of users, it's still almost
certainly a trivial amount of storage/traffic.

Keep in mind as well that we're already storing the contents of the query
tool every time the execute button is pressed, which might be dozens of
times in a session. We're talking here about adding 1 row that we just
update every 30 seconds or so.

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