Re: Regarding feature #3319

From: Dave Page <dpage(at)pgadmin(dot)org>
To: Yogesh Mahajan <yogesh(dot)mahajan(at)enterprisedb(dot)com>
Cc: pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: Regarding feature #3319
Date: 2025-03-13 11:28:45
Message-ID: CA+OCxozU15HwPYsJ9B5567QfAnxWQdgb=-3fo5NXT7Eq-EU+Rw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

Hi

On Thu, 13 Mar 2025 at 11:20, Yogesh Mahajan <
yogesh(dot)mahajan(at)enterprisedb(dot)com> wrote:

> Hi Dave,
>
> Couple of follow up questions -
>
> Thanks,
> Yogesh Mahajan
> EnterpriseDB
>
>
> On Thu, Mar 13, 2025 at 4:37 PM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
>>
>>
>> On Tue, 11 Mar 2025 at 08:31, Yogesh Mahajan <
>> yogesh(dot)mahajan(at)enterprisedb(dot)com> wrote:
>>
>>> Hello Team,
>>>
>>> Couple of more questions arose during discussion -
>>>
>>> 1.What all tools should we reopen while restoration? It could be Query
>>> tool, ERD, Psql, Schema diff as of now may get additional in future.
>>>
>>
>> Yes :-). Ideally, as much of the original state as possible should be
>> restored.
>>
>
> So, should we open the psql without data and schema diff without
> comparison results?
>

I don't see that we have any choice for psql. We absolutely should *not*
attempt to automatically re-run user queries.

For the schema diff, yes, that could be very expensive. The user can press
the button if they want to incur that cost.

> Also for the query tools open with an ad-hoc server, should we just open a
> query tool with data without connections?
>
>
>>
>>> 2.Can we use an existing crypt key to encrypt the query data or simply
>>> json encoding should be enough?
>>>
>>
>> We're already storing the query history, so we should follow the
>> precedent there.
>>
> Currently we are storing this data with json encoding done by the
> request module.
>
>
>> --
>> Dave Page
>> pgAdmin: https://www.pgadmin.org
>> PostgreSQL: https://www.postgresql.org
>> pgEdge: https://www.pgedge.com
>>
>>

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

In response to

Responses

Browse pgadmin-hackers by date

  From Date Subject
Next Message Yogesh Mahajan 2025-03-13 11:35:05 Re: Regarding feature #3319
Previous Message Dave Page 2025-03-13 11:24:37 Re: Role based access control discussion