Hi Dave, On Thu, Feb 20, 2025 at 3:22 PM Dave Page <dp...@pgadmin.org> wrote:
> > > On Thu, 20 Feb 2025 at 03:52, Aditya Toshniwal < > aditya.toshni...@enterprisedb.com> wrote: > >> Hi Dave, >> >> On Wed, Feb 19, 2025 at 6:55 PM Dave Page <dp...@pgadmin.org> wrote: >> >>> >>> >>> On Wed, 19 Feb 2025 at 12:24, Yogesh Mahajan < >>> yogesh.maha...@enterprisedb.com> wrote: >>> >>>> >>>> Hi, >>>> >>>> On Wed, Feb 19, 2025 at 5:12 PM Dave Page <dp...@pgadmin.org> wrote: >>>> >>>>> Hi >>>>> >>>>> On Thu, 16 Jan 2025 at 06:37, Aditya Toshniwal < >>>>> aditya.toshni...@enterprisedb.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"
