From: | Aditya Toshniwal <aditya(dot)toshniwal(at)enterprisedb(dot)com> |
---|---|
To: | Dave Page <dpage(at)pgadmin(dot)org> |
Cc: | Yogesh Mahajan <yogesh(dot)mahajan(at)enterprisedb(dot)com>, Anil Sahoo <anil(dot)sahoo(at)enterprisedb(dot)com>, pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org> |
Subject: | Re: Regarding feature #3319 |
Date: | 2025-02-20 03:52:11 |
Message-ID: | CAM9w-_=aB30i4Ev=Xj_jR1ysB+y_yNRXsLC2-3fJ1fd6f2CRDg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgadmin-hackers |
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.
>
> --
> 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"
From | Date | Subject | |
---|---|---|---|
Next Message | Akshay Joshi | 2025-02-20 07:18:03 | pgAdmin 4 v9.1 has been rescheduled on 13th March 2025 |
Previous Message | Anthony DeBarros | 2025-02-19 13:41:08 | Re: Regarding feature #3319 |