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. -- Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org pgEdge: https://www.pgedge.com
