Re: Some pgAdmin 4 (4.1) bugs
Hello Khushboo, thank you very much for your response!
On 29/01/2019 11.35, Khushboo Vashi wrote:
> Hi Arni,
>
> On Tue, Jan 29, 2019 at 3:24 PM Arni Kromić <mailto:arni.kro...@bios-ict.hr>> wrote:
>
> The new bug is in the UI, specifically in the query "window".
> While the
> lower half which contains "Data Output", "Explain" etc. can be
> undocked
> from its position and become a floating window, it cannot be docked
> back. If I undock single items ("DataOutput" etc.) from that window, I
> can dock them one by one back to the original position, but not the
> entire window.
>
>
> This is the expected behaviour.
>
> It's annoying because it can happen when you try to resize the top of
> the window; you can easily miss the thin line (changing cursor to
> double-arrow)
>
>
> We are working on this, please refer
> https://redmine.postgresql.org/issues/3865
>
> and hit the "top bar" of that window and yank it out of
> its docking position - this is how I found out. Since it can't be
> returned to its original position as it is, you need to drag all four
> tabs one by one back to the position.
>
Actually, I don't mind much the thin resize-divider per se; I don't need
it too often. However I do mind that you cannot re-dock the lower window
after you undock it! It's definitely not "expected behaviour" in my book.
The mentioned issue does not cover this and I would like to log a new
report for it, because I definitely find it annoying and distracting...
> The other bug I've noticed before concerns the "Create - Sequence"
> functionality. If I enter a negative Increment, it complains:
> "Increment' must be greater than or equal to 1." Since Postgres does
> accept negative increments (i.e. descending sequences). This is
> strange,
> since descending sequences ARE mentioned in the help; if there is
> a way
> to specify them, I haven't found it...
>
> Please log the
> issue @ https://redmine.postgresql.org/projects/pgadmin4/issues
>
Thanks, I'll do it as soon as I get to it.
> There is also a minor (possible) bug in the "Create - Function /
> Procedure" dialog - when you enter code in the window, the
> resulting SQL
> is something like "AS $BODY$select this from that$BODY$;". While it
> doesn't affect functionality, the readability of the CREATE code
> is, so
> I prefer to put newlines on the first and last lines of Code input.
> There is one example where the code is somewhat messed up though, and
> that's when the last line of code is a comment. Then the resulting SQL
> contains something like this:
>
> AS $BODY$select this from that
> --comment$BODY$;
>
> The closing $BODY$ thus gets commented out.
>
> This one is already logged. https://redmine.postgresql.org/issues/3851
That's great, I look forward for the fix.
>
>
> Another glitch new to 4.1 is that SQL tab is not visible when a new
> "Create - Function / Procedure" window is open - it has to be
> widened a
> bit for that tab to show. Also there is no indication that tab
> exists -
> if I didn't expect it to be there, I wouldn't've even tried
> looking for it.
>
> This issue has already been fixed and will be available in the next
> release.
Excellent, thanks!
>
> Please tell me if those issues should be or have been reported, and
> should I do it (and where) or someone else would. Thank you for your
> patience!
>
> --
> Kind Regards,
> Arni Kromić
>
> Thanks,
> Khushboo
--
Kind Regards,
Arni Kromić
Some pgAdmin 4 (4.1) bugs
Hello everybody. Before everything, I'd like to thank pgAdmin devs for
all the great work!
So, I've upgraded pgAdmin yesterday, and I've noticed a bug i haven't
noticed before, so I thought I should mention it, together with a couple
of bugs I've already encountered before.
The new bug is in the UI, specifically in the query "window". While the
lower half which contains "Data Output", "Explain" etc. can be undocked
from its position and become a floating window, it cannot be docked
back. If I undock single items ("DataOutput" etc.) from that window, I
can dock them one by one back to the original position, but not the
entire window.
It's annoying because it can happen when you try to resize the top of
the window; you can easily miss the thin line (changing cursor to
double-arrow) and hit the "top bar" of that window and yank it out of
its docking position - this is how I found out. Since it can't be
returned to its original position as it is, you need to drag all four
tabs one by one back to the position. Specifically, if you enter a
negative Increment, p
The other bug I've noticed before concerns the "Create - Sequence"
functionality. If I enter a negative Increment, it complains:
"Increment' must be greater than or equal to 1." Since Postgres does
accept negative increments (i.e. descending sequences). This is strange,
since descending sequences ARE mentioned in the help; if there is a way
to specify them, I haven't found it...
There is also a minor (possible) bug in the "Create - Function /
Procedure" dialog - when you enter code in the window, the resulting SQL
is something like "AS $BODY$select this from that$BODY$;". While it
doesn't affect functionality, the readability of the CREATE code is, so
I prefer to put newlines on the first and last lines of Code input.
There is one example where the code is somewhat messed up though, and
that's when the last line of code is a comment. Then the resulting SQL
contains something like this:
AS $BODY$select this from that
--comment$BODY$;
The closing $BODY$ thus gets commented out.
Another glitch new to 4.1 is that SQL tab is not visible when a new
"Create - Function / Procedure" window is open - it has to be widened a
bit for that tab to show. Also there is no indication that tab exists -
if I didn't expect it to be there, I wouldn't've even tried looking for it.
Please tell me if those issues should be or have been reported, and
should I do it (and where) or someone else would. Thank you for your
patience!
--
Kind Regards,
Arni Kromić
Re: Some pgAdmin bugs...
On 10/09/2019 18.36, Avin Kavish wrote: > Isn't there some internal uniqueness tracking mechanism? Object IDs or > something? > > On Tue., 10 Sep. 2019, 9:56 pm Dave Page, <mailto:dp...@pgadmin.org>> wrote: > > > > On Tue, Sep 10, 2019 at 9:24 AM Arni Kromić > mailto:arni.kro...@bios-ict.hr>> wrote: > > On 10/09/2019 14.42, richard coleman wrote: >> Dave, >> >> While I agree it's generally a good idea to have a primary >> key, the solution as currently implemented leaves the user >> unable to edit, or in this case to even add a record to table >> without one. I would suggest either having pgAdmin4 compute >> some sort of an /internal key/ for cases like this, or in the >> alternative *disable* those features (such as View/*Edit*) >> that have not been implemented for cases such as this. >> Perhaps with a dialog informing the user that "Editing or >> adding data isn't supported on tables without a primary key". >> >> rik. >> > I agree this is a corner case as mentioned. However, sometimes > PK-s (or indexes) are simply not needed, say if the table is > insert-only most of the time and its data gets dumped without > any filters, and nothing ever needs to be deleted. I believe > Inserts should also work from pgAdmin as they do from code. > > So, should a issue be raised, or is it already decided this is > a "wontfix"? > > > No, it's not decided. Feel free to add a feature request, but it's > likely to be considered low priority. > Great, I think I'll do it, for the sake of completeness. I believe there is no need to create workarounds for updates and/or deletes in this case; they should remain disabled when there is no PK. Just inserts (the "empty row" in this case) should be made possible. > > > ... > > > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > -- Kind Regards, Arni Kromić
Re: Some pgAdmin bugs...
On 10/09/2019 13.43, Arni Kromić wrote: > Working with pgAdmin, I've found several bugs. Not sure if they are > already reported; couldn't find them on Redmine, but perhaps I missed > them. Maybe someone will recognize if they've already been reported. > Here it goes... Forgot to mention software version, it's pgAdmin 4.12 installed from the upstream apt repo on Ubuntu 18.04LTS. -- Kind Regards, Arni Kromić
Re: Some pgAdmin bugs...
On 10/09/2019 13.58, Aditya Toshniwal wrote: > Hi, > > On Tue, Sep 10, 2019 at 5:13 PM Arni Kromić <mailto:arni.kro...@bios-ict.hr>> wrote: > > Working with pgAdmin, I've found several bugs. Not sure if they > are already reported; couldn't find them on Redmine, but perhaps I > missed them. Maybe someone will recognize if they've already been > reported. Here it goes... > > 1) When doing View/Edit on an empty table, I cannot insert > anything when it opens. There is no empty row I can write into, > like there is when a table has at least one row already. In fact, > there are no rows at all, just the header. > > I tried. I get an empty row to enter > Screenshot 2019-09-10 at 17.25.25.png > > > > 2) Create Sequence dialog doesn't accept negative values for > Increment (Error msg: > Increment' must be greater than or equal to 1.) Postgres does > accept negative increment, so should this dialog. > > Kindly raise here > - https://redmine.postgresql.org/projects/pgadmin4/issues/new Done: https://redmine.postgresql.org/issues/4726 > > 3) EXEC Script context menu for Procedures works incorrectly - > doesn't write the script to the end. An example, procedure with > many parameters: > > Its a bug - Kindly raise here > - https://redmine.postgresql.org/projects/pgadmin4/issues/new Here it is: https://redmine.postgresql.org/issues/4727 > ... > > 4) This one is not a biggie, but it would be nice if it is fixed. > Code inserted in the Code tab of the Create/Properties dialog for > functions and procedures is put within $BODY$ tags without any > newlines. So, if I write a new function/procedure and write this > in the editor on the Code tab (shown together with line numbers I > see): > > Yes. Its been logged - https://redmine.postgresql.org/issues/3851 Great! I hope at least the missing newlines will be fixed soon. :) > ... > > -- > Kind Regards, > Arni Kromić > > > > -- > Thanks and Regards, > Aditya Toshniwal > Software Engineer | EnterpriseDB India | Pune > "Don't Complain about Heat, Plant a TREE" -- Kind Regards, Arni Kromić
Some pgAdmin bugs...
Working with pgAdmin, I've found several bugs. Not sure if they are already reported; couldn't find them on Redmine, but perhaps I missed them. Maybe someone will recognize if they've already been reported. Here it goes... 1) When doing View/Edit on an empty table, I cannot insert anything when it opens. There is no empty row I can write into, like there is when a table has at least one row already. In fact, there are no rows at all, just the header. 2) Create Sequence dialog doesn't accept negative values for Increment (Error msg: Increment' must be greater than or equal to 1.) Postgres does accept negative increment, so should this dialog. 3) EXEC Script context menu for Procedures works incorrectly - doesn't write the script to the end. An example, procedure with many parameters: CREATE OR REPLACE PROCEDURE public.dodaj_klijenta( v_naziv character varying, v_oib character varying, v_pdv_id character varying, v_adresa character varying, v_mjesto integer, v_drzava character varying, v_tip_p_sub character varying, v_vlasnik character varying, v_pdv boolean, v_fisk boolean, v_iban character varying, v_k_osoba character varying, v_email character varying, v_br_tel character varying, v_radna_god numeric, v_schema character varying) ... The EXEC Script for it is generated exactly thus: CALL public.dodaj_klijenta( , As you can see, it is cut off very early. A notice, this is only for procedures; EXEC Scripts for functions with many arguments work fine. 4) This one is not a biggie, but it would be nice if it is fixed. Code inserted in the Code tab of the Create/Properties dialog for functions and procedures is put within $BODY$ tags without any newlines. So, if I write a new function/procedure and write this in the editor on the Code tab (shown together with line numbers I see): 1 select * from keyring 2 --some comment The function is created containing this: ... AS $BODY$select * from keyring --tralala$BODY$; ... Although it apparently doesn't harm the code, it is visually ugly and the syntax-highlighting colors the second line as comment, so the closing $BODY$ appears commented (a bit confusing to see). So to make it look normal, I have to prepend and append a newline: 1 2 select * from keyring 3 --some comment 4 ...to get a more acceptable code: ... AS $BODY$ select * from keyring --tralala $BODY$; ... So I propose those newlines should be added automatically. Please advise if I need to report the above problems on Redmine, or perhaps do something else... -- Kind Regards, Arni Kromić
Re: Some pgAdmin bugs...
On 10/09/2019 14.42, richard coleman wrote: > Dave, > > While I agree it's generally a good idea to have a primary key, the > solution as currently implemented leaves the user unable to edit, or > in this case to even add a record to table without one. I would > suggest either having pgAdmin4 compute some sort of an /internal > key/ for cases like this, or in the alternative *disable* those > features (such as View/*Edit*) that have not been implemented for > cases such as this. Perhaps with a dialog informing the user that > "Editing or adding data isn't supported on tables without a primary key". > > rik. > I agree this is a corner case as mentioned. However, sometimes PK-s (or indexes) are simply not needed, say if the table is insert-only most of the time and its data gets dumped without any filters, and nothing ever needs to be deleted. I believe Inserts should also work from pgAdmin as they do from code. So, should a issue be raised, or is it already decided this is a "wontfix"? -- Kind Regards, Arni Kromić > On Tue, Sep 10, 2019 at 8:34 AM Dave Page <mailto:dp...@pgadmin.org>> wrote: > > > > On Tue, Sep 10, 2019 at 8:24 AM richard coleman > mailto:rcoleman.ascen...@gmail.com>> > wrote: > > Hi All, > > My $0.02. Tested the first one here (Kubuntu 18.04, Chromium, > pgAdmin 4 4.12) with mixed results. > > On Tue, Sep 10, 2019 at 7:59 AM Aditya Toshniwal > <mailto:aditya.toshni...@enterprisedb.com>> wrote: > > Hi, > > On Tue, Sep 10, 2019 at 5:13 PM Arni Kromić > mailto:arni.kro...@bios-ict.hr>> > wrote: > > Working with pgAdmin, I've found several bugs. Not > sure if they are already reported; couldn't find them > on Redmine, but perhaps I missed them. Maybe someone > will recognize if they've already been reported. Here > it goes... > > 1) When doing View/Edit on an empty table, I cannot > insert anything when it opens. There is no empty row I > can write into, like there is when a table has at > least one row already. In fact, there are no rows at > all, just the header. > > I tried. I get an empty row to enter > Screenshot 2019-09-10 at 17.25.25.png > > > Test table0: two columns both character varying columns, no > primary key, View/Edit opens without any rows as the original > poster Arni wrote. > > Test table1: three columns, two character varying, one primary > key bigint, View/Edit opens with a single blank row as Aditya > reported. > > Does Arni's table have a primary key defined? Is it a > bigint? It looks like there might be a bug where pgAdmin4 > isn't presenting a row to add a record from the View/Edit > function if there isn't a primary key, or a particular type of > primary key defined on the table. > > > If memory serves that was a design choice when the code was > implemented. We cannot safely allow editing without a primary key, > and adding rows (which arguably is safe) is considered editing as > the code is currently implemented. > > I consider this a corner-case; typically one would have a primary > key on a table to identify individual rows, and most cases where > you wouldn't are probably not ones where you'd ever try to edit or > manually add data (consider something like sensor output data). > I'm not sure how much demand there would be for doing this; > clearly not a huge amount. > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
Schema backup failure
We've found a problem backing up some of our schemas from pgAdmin4. After some investigation, we've found the problem being the schema names need ident quoting - apparently because they contain capital letters. For example, pgAdmin generated this code which fails: > $ /usr/bin/pg_dump --file "testera" --host "/var/run/postgresql" > --port "5432" --username "postgres" --no-password --verbose --format=c > --blobs --schema "HR001-2019" "nubes" > pg_dump: last built-in OID is 16383 > pg_dump: no matching schemas were found However, if I quote the schema name by adding a pair of single quotes... > $ /usr/bin/pg_dump --file "testera" --host "/var/run/postgresql" > --port "5432" --username "postgres" --no-password --verbose --format=c > --blobs --schema '"HR001-2019"' "nubes" > pg_dump: last built-in OID is 16383 > pg_dump: reading extensions > pg_dump: identifying extension members > pg_dump: reading schemas > pg_dump: reading user-defined tables > pg_dump: reading user-defined functions > pg_dump: reading user-defined types > ... ...it works fine. So it seems schema names should be automatically quoted (similar to quote_ident()) for backup to work properly. I guess this is a bug in pgAdmin4 (version I have is 4.11). -- Srdačan pozdrav / Kind regards --- Arni Kromić [ IT system engineer ] arni.kro...@bios-ict.hr Tel: +385 21 490 599 Mob: +385 95 659 5 659 -- Mažuranićevo šet. 14 21000 Split, Croatia Tel: +385 21 344 349 Fax: +358 21 490 599 http://podrska.bios-ict.hr http://www.bios-ict.hr --
Re: Session timeout
On 17/10/2019 15.24, Arni Kromić wrote: > On 17/10/2019 11.05, Khushboo Vashi wrote: >> Hi Arni, >> >> On Thu, Oct 17, 2019 at 1:41 PM Arni Kromić > <mailto:arni.kro...@bios-ict.hr>> wrote: >> >> A question asked on the list reminded me of something... I've always >> wondered if it's possible to prolong or prevent pgAdmin4 session >> timeouts. This way if I leave the computer for a long time >> (especially >> if it gets suspended), I have to refresh page, and login again. That >> also means that any query/data tabs are lost. >> >> Can i prevent the session from expiring so I can stay logged in? >> I don't >> need this at all for security because both the database and the >> pgAdmin >> service are on my development computer which only I use. >> >> No, you can't prevent the session expiration completely but, you can >> increase the timeout limits. >> Check the below configurations in config.py file. >> >> MAX_SESSION_IDLE_TIME >> SESSION_EXPIRATION_TIME >> CHECK_SESSION_FILES_INTERVAL >> >> You will get information regarding the parameters in the file itself, >> and can override above settings as per your requirement. >> >> Thanks, >> Khushboo >> > > Thank you very much, I believe this is exactly what I need. I've tuned > those parameters on my development machine to work more comfortably, I > hope it will do the trick. > > -- > Kind Regards, > Arni Kromić Unfortunately this didn't solve the problem. I've prolonged the first parameter from 1 hour to 24 and the other two from one day to three; but when I put the computer to sleep yesterday afternoon and woke it up this morning, it required relogin. Again I couldn't stop the work and continue. I don't know if anything else is needed to apply the settings, I just restarted Apache and re-login to pgAdmin. I've also observed that the same session does continue normally if I leave the computer for a few hours and it also survives when I put the computer to sleep and wake it up after a short while. Why does it not listen to my changed configuration? The file I edited is /usr/share/pgadmin4/web/config.py, which I suppose is the right one for my computer. The software was installed on Ubuntu from upstream (your) apt repository. -- Kind Regards, Arni Kromić
Re: Saving DDL to a file ...
On 18/10/2019 07.01, Avin Kavish wrote: > Can't you copy and paste it? > > On Fri., 18 Oct. 2019, 9:27 am Khushboo Vashi, > <mailto:khushboo.va...@enterprisedb.com>> wrote: > > Hi Michael, > > On Thu, Oct 17, 2019 at 10:31 PM Michael Shapiro > mailto:mshapir...@gmail.com>> wrote: > > When I look at the DDL for an object (eg view or function) > under the SQL tab in PgAdmin4, how do I save it to a file? > > Not supported right now but we do have a feature request for the > same. Ref: https://redmine.postgresql.org/issues/4493 > > Also, is there a way to run the DDL in a different database > (so I can "copy" the object from one database to another) > > No, I'm afraid. > > Thanks, > Khushboo > > Every object should also have "CREATE script" context menu item which opens in the Query Tool and can be saved from there... -- Kind Regards, Arni Kromić
Re: Restore item in server menu (suggestion)
On 11/10/2019 06.05, Khushboo Vashi wrote: > Hi, > > On Thu, Oct 10, 2019 at 3:50 PM Arni Kromić <mailto:arni.kro...@bios-ict.hr>> wrote: > > A pgAdmin4 feature I have always wanted is having some "restore" > command in the server or Databases context menu. That would make > restoring databases much easier, especially during development and > testing when various changes occur frequently. > > Currently there are two options for restoring databases in pgAdmin > from custom format backups, both a bit inconvenient: > > 1. Manually create database with the required name, then use > Restore from its context menu; this has more steps than needed > - there is no need to create the database manually > 2. Use Restore from any existing database's menu, enabling the > "CREATE DATABASE" option; faster, but potentially dangerous or > inconvenient if one manages to overwrite the other database by > mistake > > For someone frequently dumping and restoring various databases > from within pgAdmin4 while also doing development in it, the new > menu item would be quite useful. Alternatively, it could be added > as an option in the Create / Database menu; something like "Create > Database from backup". > > Please create a feature > request @ https://redmine.postgresql.org/projects/pgadmin4, we will > analyse it and will proceed further accordingly. > > Thanks, > Khushboo > > -- > Kind Regards, > Arni Kromić > Thank you, feature request created: https://redmine.postgresql.org/issues/4832 -- Kind Regards, Arni Kromić
Re: Session timeout
On 18/10/2019 09.09, Arni Kromić wrote:
> On 17/10/2019 15.24, Arni Kromić wrote:
>> On 17/10/2019 11.05, Khushboo Vashi wrote:
>>> Hi Arni,
>>>
>>> On Thu, Oct 17, 2019 at 1:41 PM Arni Kromić >> <mailto:arni.kro...@bios-ict.hr>> wrote:
>>>
>>> A question asked on the list reminded me of something... I've always
>>> wondered if it's possible to prolong or prevent pgAdmin4 session
>>> timeouts. This way if I leave the computer for a long time
>>> (especially
>>> if it gets suspended), I have to refresh page, and login again. That
>>> also means that any query/data tabs are lost.
>>>
>>> Can i prevent the session from expiring so I can stay logged in?
>>> I don't
>>> need this at all for security because both the database and the
>>> pgAdmin
>>> service are on my development computer which only I use.
>>>
>>> No, you can't prevent the session expiration completely but, you can
>>> increase the timeout limits.
>>> Check the below configurations in config.py file.
>>>
>>> MAX_SESSION_IDLE_TIME
>>> SESSION_EXPIRATION_TIME
>>> CHECK_SESSION_FILES_INTERVAL
>>>
>>> You will get information regarding the parameters in the file
>>> itself, and can override above settings as per your requirement.
>>>
>>> Thanks,
>>> Khushboo
>>>
>>
>> Thank you very much, I believe this is exactly what I need. I've
>> tuned those parameters on my development machine to work more
>> comfortably, I hope it will do the trick.
>>
>> --
>> Kind Regards,
>> Arni Kromić
> Unfortunately this didn't solve the problem. I've prolonged the first
> parameter from 1 hour to 24 and the other two from one day to three;
> but when I put the computer to sleep yesterday afternoon and woke it
> up this morning, it required relogin. Again I couldn't stop the work
> and continue.
>
> I don't know if anything else is needed to apply the settings, I just
> restarted Apache and re-login to pgAdmin. I've also observed that the
> same session does continue normally if I leave the computer for a few
> hours and it also survives when I put the computer to sleep and wake
> it up after a short while. Why does it not listen to my changed
> configuration?
>
> The file I edited is /usr/share/pgadmin4/web/config.py, which I
> suppose is the right one for my computer. The software was installed
> on Ubuntu from upstream (your) apt repository.
> --
> Kind Regards,
> Arni Kromić
Ok so is there anything else I should try to prevent the session to
expire by the next day? Or is it possibly a bug to report if pgAdmin
doesn't really care about those settings?
But, I'd say there is definitely one bug present, an unwanted behavior.
When the login session becomes invalit, the interface stays the same,
but it just spits all kinds of errors when you try to do anything
("Would you like to reconnect to the database?" then various invalid
this and that errors.) The correct behavior would be to automatically
redirect to the login page if the login session expires. Should this be
reported?
--
Kind Regards,
Arni Kromić
Re: Session timeout
On 17/10/2019 11.05, Khushboo Vashi wrote: > Hi Arni, > > On Thu, Oct 17, 2019 at 1:41 PM Arni Kromić <mailto:arni.kro...@bios-ict.hr>> wrote: > > A question asked on the list reminded me of something... I've always > wondered if it's possible to prolong or prevent pgAdmin4 session > timeouts. This way if I leave the computer for a long time (especially > if it gets suspended), I have to refresh page, and login again. That > also means that any query/data tabs are lost. > > Can i prevent the session from expiring so I can stay logged in? I > don't > need this at all for security because both the database and the > pgAdmin > service are on my development computer which only I use. > > No, you can't prevent the session expiration completely but, you can > increase the timeout limits. > Check the below configurations in config.py file. > > MAX_SESSION_IDLE_TIME > SESSION_EXPIRATION_TIME > CHECK_SESSION_FILES_INTERVAL > > You will get information regarding the parameters in the file itself, > and can override above settings as per your requirement. > > Thanks, > Khushboo > Thank you very much, I believe this is exactly what I need. I've tuned those parameters on my development machine to work more comfortably, I hope it will do the trick. -- Kind Regards, Arni Kromić
Session timeout
A question asked on the list reminded me of something... I've always wondered if it's possible to prolong or prevent pgAdmin4 session timeouts. This way if I leave the computer for a long time (especially if it gets suspended), I have to refresh page, and login again. That also means that any query/data tabs are lost. Can i prevent the session from expiring so I can stay logged in? I don't need this at all for security because both the database and the pgAdmin service are on my development computer which only I use. -- Kind Regards, Arni Kromić
Re: Session timeout
On 30/10/2019 06.15, Khushboo Vashi wrote:
>
> Ok so is there anything else I should try to prevent the session
> to expire by the next day? Or is it possibly a bug to report if
> pgAdmin doesn't really care about those settings?
>
> Let me verify it, will get back to you.
>
>
Thank you, I appreciate your effort!
> But, I'd say there is definitely one bug present, an unwanted
> behavior. When the login session becomes invalit, the interface
> stays the same, but it just spits all kinds of errors when you try
> to do anything ("Would you like to reconnect to the database?"
> then various invalid this and that errors.) The correct behavior
> would be to automatically redirect to the login page if the login
> session expires. Should this be reported?
>
--
Kind Regards,
Arni Kromić
Restore item in server menu (suggestion)
A pgAdmin4 feature I have always wanted is having some "restore" command in the server or Databases context menu. That would make restoring databases much easier, especially during development and testing when various changes occur frequently. Currently there are two options for restoring databases in pgAdmin from custom format backups, both a bit inconvenient: 1. Manually create database with the required name, then use Restore from its context menu; this has more steps than needed - there is no need to create the database manually 2. Use Restore from any existing database's menu, enabling the "CREATE DATABASE" option; faster, but potentially dangerous or inconvenient if one manages to overwrite the other database by mistake For someone frequently dumping and restoring various databases from within pgAdmin4 while also doing development in it, the new menu item would be quite useful. Alternatively, it could be added as an option in the Create / Database menu; something like "Create Database from backup". -- Kind Regards, Arni Kromić
