Re: how to run several versions of pgAdmin on the same pc

[Cherio]

Same here. We have a lot of 9.x instances as well.
So the choice is either not upgrade or upgrade and have e.g. SquirrelSQL
for everything else.

On Tue, Sep 27, 2022 at 4:07 PM john fabiani  wrote:

> I agree - there are plenty of 9.x installs still running.
>
> Johnf
>
> On 9/26/22 3:31 AM, Skrol29 wrote:
> > Hi,
> >
> > PostgreSQL version 9 is no loger supported by pgAdmin 4 since v6.13.
> > I have several PostgreSQL servers : versions 9 and higher. So how can
> > run on the same computer both pgAdmin 4 v6.12, and pgAdmin 4 last
> > version in order to manage all the servers ?
> >
> > I have Windows 11 with pgAdmin 4 v6.14 installed
> >
> > If a start an install of pgAdmin 4 v6.12 it says that a higher version
> > is already installed.
> >
> > I have checked the command line options, and there is nothing
> > concerning bypassing the version check, or pre-selecting the target
> > folder.
> > https://jrsoftware.org/ishelp/index.php?topic=setupcmdline
> >
> > Regards,
> > Skrol29
> >
>
>
>

Re: Content assist / autocomplete hangs the server (latest pgAdmin version)

[Cherio]

Thanks Akshay, that's what I meant by "switched autocomplete to manual".

That however doesn't really address the issue. I can still bring down the
pgAdmin backend (for everyone using it) by clicking Ctrl+Space on a
complex/rogue SQL.

On Fri, Aug 5, 2022 at 4:35 AM Akshay Joshi 
wrote:

> Hi Cherio
>
> You can disable the automatic autocomplete option from "File ->
> Preferences -> Query Tool -> Auto completion -> Autocomplete on key press".
> We have also fixed an issue to stop autocomplete on arrow keys #7573
> <https://redmine.postgresql.org/issues/7573> which will be available in
> the next release, meanwhile, you can install the snapshot build
> <https://www.postgresql.org/ftp/pgadmin/pgadmin4/snapshots/>.
>
>
>
> On Wed, Aug 3, 2022 at 11:39 PM Cherio  wrote:
>
>> I had to examine certain aspects of a query that looks like this:
>>
>> SELECT COUNT(*)
>> FROM schema.table
>> WHERE id IN (
>> '1',
>> '2',
>> '3',
>> 
>> '19998',
>> '1',
>> '2'
>> )
>>
>> I pasted the query and autocomplete kicked in. For a minute it froze
>> entirely. Then it sort of let me do things but everything was like in slow
>> motion: the tree browser, the other SQL tabs - everything became slow as
>> molasses. I logged onto the server and the "pgAdmin4.py" was
>> keeping the CPU quite busy. It didn't recover for some time so I simply
>> restarted the server and switched autocomplete to manual.
>>
>> Not knowing the design I may not be able to make a viable suggestion but
>> maybe some sort of complexity counter (configurable or at least hard-coded
>> at first) should be considered, which would hint to the autocomplete to
>> stop trying, after it realizes the task may be too complex or takes too
>> long to complete.
>>
>> Sure, a query like the one above should probably make use of a temporary
>> table but it is beyond the point - there has to be a safeguard against an
>> overloaded autocomplete. Without such a safeguard an ugly/invalid query or
>> a user error could kill the server for all connected pgadmin clients.
>>
>>>
>
> --
>
> <http://www.enterprisedb.com>
>
> Akshay Joshi
>
> Principal Software Architect
>
> +91 9767888246
>
> www.enterprisedb.com
>
> <https://www.linkedin.com/company/edbpostgres>
> <https://twitter.com/edbpostgres?lang=en>
> <https://www.facebook.com/EDBpostgres>
> <https://www.instagram.com/EDBpostgres/>
>

Content assist / autocomplete hangs the server (latest pgAdmin version)

[Cherio]

I had to examine certain aspects of a query that looks like this:

SELECT COUNT(*)
FROM schema.table
WHERE id IN (
'1',
'2',
'3',

'19998',
'1',
'2'
)

I pasted the query and autocomplete kicked in. For a minute it froze
entirely. Then it sort of let me do things but everything was like in slow
motion: the tree browser, the other SQL tabs - everything became slow as
molasses. I logged onto the server and the "pgAdmin4.py" was
keeping the CPU quite busy. It didn't recover for some time so I simply
restarted the server and switched autocomplete to manual.

Not knowing the design I may not be able to make a viable suggestion but
maybe some sort of complexity counter (configurable or at least hard-coded
at first) should be considered, which would hint to the autocomplete to
stop trying, after it realizes the task may be too complex or takes too
long to complete.

Sure, a query like the one above should probably make use of a temporary
table but it is beyond the point - there has to be a safeguard against an
overloaded autocomplete. Without such a safeguard an ugly/invalid query or
a user error could kill the server for all connected pgadmin clients.

>

Re: Upgradede Pgadmin4 to v6.12 - new startup error

[Cherio]

Thanks Dave! The application started after I added the line you suggested
. Although in my opinion, trying to work around a new feature in order
to start pgadmin feels wrong.

I have 2 follow-up questions.

1. Presently I have to redefine paths for several files and directories
(see below). Is there a better way/place to define DATA_DIR so that
subdirectories and files in it need not be explicitly redefined? It just
doesn't feel like a good design pattern :)

LOG_FILE = os.path.join(DATA_DIR, 'pgadmin4.log')
SQLITE_PATH = os.path.join(DATA_DIR, 'pgadmin4.db')
SESSION_DB_PATH = os.path.join(DATA_DIR, 'sessions')
STORAGE_DIR = os.path.join(DATA_DIR, 'storage')
AZURE_CREDENTIAL_CACHE_DIR = os.path.join(DATA_DIR, 'azurecredentialcache')

2. I am guessing the new "azurecredentialcache" directory is related to the
new feature that adds "support for Azure PostgreSQL deployment in server
mode". Why is it trying to create new directories in an environment that
has nothing to do with Azure?


On Mon, Aug 1, 2022 at 11:10 AM Dave Page  wrote:

> Hi
>
> On Mon, 1 Aug 2022 at 16:01, Cherio  wrote:
>
>> I grepped the sources for 'azurecredentialcache':
>>
>> user@HOST:~/opt/pgadmin4$ grep -R azurecredentialcache .
>> ./lib/python3.8/site-packages/pgadmin4/config.py:AZURE_CREDENTIAL_CACHE_DIR
>> = os.path.join(DATA_DIR, 'azurecredentialcache')
>>
>> I do re-define DATA_DIR in my configuration file (see below) so it is
>> unclear why it is trying to create something in "/var/lib/pgadmin":
>>
>
> Almost certainly because config_local.py is read at the end of config.py,
> so the change you make to DATA_DIR isn't reflected by
> AZURE_CREDENTIAL_CACHE_DIR.
>
>
>>
>> user@HOST:~/opt/pgadmin4$ cat
>> ./lib/python3.8/site-packages/pgadmin4/config_local.py
>> import os
>> DATA_DIR = os.path.realpath(os.path.expanduser(u'~/.config/pgadmin-v4/'))
>> LOG_FILE = os.path.join(DATA_DIR, 'pgadmin4.log')
>> SQLITE_PATH = os.path.join(DATA_DIR, 'pgadmin4.db')
>> SESSION_DB_PATH = os.path.join(DATA_DIR, 'sessions')
>> STORAGE_DIR = os.path.join(DATA_DIR, 'storage')
>> PGADMIN_INT_PORT=
>> DEFAULT_SERVER_PORT=
>> SERVER_MODE = False
>> MASTER_PASSWORD_REQUIRED = False
>>
>
> Try adding the following to config_local.py:
>
> AZURE_CREDENTIAL_CACHE_DIR = os.path.join(DATA_DIR, 'azurecredentialcache')
>
> That will ensure it gets reset after you redefine DATA_DIR.
>
> I think we have some docs/comments about re-defining things if you change
> DATA_DIR; I'll go check they mention AZURE_CREDENTIAL_CACHE_DIR as well.
>
>
>>
>> I skipped version 6.11 and upgraded from 6.10 so I can't say whether this
>> broke in 6.11 or 6.12.
>>
>> On Mon, Aug 1, 2022 at 10:09 AM Cherio  wrote:
>>
>>> This was just a regular upgrade (I went through dozens of these).
>>> The new 6.12 version fails to start with the following error message:
>>>
>>>   File "lib/python3.8/site-packages/pgadmin4/pgAdmin4.py", line 93, in
>>> 
>>> app = create_app()
>>>   File
>>> "/path-to/opt/pgadmin4/lib/python3.8/site-packages/pgadmin4/pgadmin/__init__.py",
>>> line 270, in create_app
>>> create_app_data_directory(config)
>>>   File
>>> "/path-to/opt/pgadmin4/lib/python3.8/site-packages/pgadmin4/pgadmin/setup/data_directory.py",
>>> line 117, in create_app_data_directory
>>> _create_directory_if_not_exists(config.AZURE_CREDENTIAL_CACHE_DIR)
>>>   File
>>> "/path-to/opt/pgadmin4/lib/python3.8/site-packages/pgadmin4/pgadmin/setup/data_directory.py",
>>> line 20, in _create_directory_if_not_exists
>>> os.mkdir(_path)
>>> FileNotFoundError: [Errno 2] No such file or directory:
>>> '/var/lib/pgadmin/azurecredentialcache'
>>>
>>> My setup has absolutely nothing to do with Azure. I use python wheel
>>> having PgAdmin installed in an unprivileged environment, so I am puzzled
>>> why it is all of sudden trying to look for something in "/var/lib/pgadmin"
>>> or create things there?
>>>
>>>
>
> --
> Dave Page
> Blog: https://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EDB: https://www.enterprisedb.com
>
>

Re: Upgradede Pgadmin4 to v6.12 - new startup error

[Cherio]

I grepped the sources for 'azurecredentialcache':

user@HOST:~/opt/pgadmin4$ grep -R azurecredentialcache .
./lib/python3.8/site-packages/pgadmin4/config.py:AZURE_CREDENTIAL_CACHE_DIR
= os.path.join(DATA_DIR, 'azurecredentialcache')

I do re-define DATA_DIR in my configuration file (see below) so it is
unclear why it is trying to create something in "/var/lib/pgadmin":

user@HOST:~/opt/pgadmin4$ cat
./lib/python3.8/site-packages/pgadmin4/config_local.py
import os
DATA_DIR = os.path.realpath(os.path.expanduser(u'~/.config/pgadmin-v4/'))
LOG_FILE = os.path.join(DATA_DIR, 'pgadmin4.log')
SQLITE_PATH = os.path.join(DATA_DIR, 'pgadmin4.db')
SESSION_DB_PATH = os.path.join(DATA_DIR, 'sessions')
STORAGE_DIR = os.path.join(DATA_DIR, 'storage')
PGADMIN_INT_PORT=
DEFAULT_SERVER_PORT=
SERVER_MODE = False
MASTER_PASSWORD_REQUIRED = False

I skipped version 6.11 and upgraded from 6.10 so I can't say whether this
broke in 6.11 or 6.12.

On Mon, Aug 1, 2022 at 10:09 AM Cherio  wrote:

> This was just a regular upgrade (I went through dozens of these).
> The new 6.12 version fails to start with the following error message:
>
>   File "lib/python3.8/site-packages/pgadmin4/pgAdmin4.py", line 93, in
> 
> app = create_app()
>   File
> "/path-to/opt/pgadmin4/lib/python3.8/site-packages/pgadmin4/pgadmin/__init__.py",
> line 270, in create_app
> create_app_data_directory(config)
>   File
> "/path-to/opt/pgadmin4/lib/python3.8/site-packages/pgadmin4/pgadmin/setup/data_directory.py",
> line 117, in create_app_data_directory
> _create_directory_if_not_exists(config.AZURE_CREDENTIAL_CACHE_DIR)
>   File
> "/path-to/opt/pgadmin4/lib/python3.8/site-packages/pgadmin4/pgadmin/setup/data_directory.py",
> line 20, in _create_directory_if_not_exists
> os.mkdir(_path)
> FileNotFoundError: [Errno 2] No such file or directory:
> '/var/lib/pgadmin/azurecredentialcache'
>
> My setup has absolutely nothing to do with Azure. I use python wheel
> having PgAdmin installed in an unprivileged environment, so I am puzzled
> why it is all of sudden trying to look for something in "/var/lib/pgadmin"
> or create things there?
>
>

Upgradede Pgadmin4 to v6.12 - new startup error

[Cherio]

This was just a regular upgrade (I went through dozens of these).
The new 6.12 version fails to start with the following error message:

  File "lib/python3.8/site-packages/pgadmin4/pgAdmin4.py", line 93, in

app = create_app()
  File
"/path-to/opt/pgadmin4/lib/python3.8/site-packages/pgadmin4/pgadmin/__init__.py",
line 270, in create_app
create_app_data_directory(config)
  File
"/path-to/opt/pgadmin4/lib/python3.8/site-packages/pgadmin4/pgadmin/setup/data_directory.py",
line 117, in create_app_data_directory
_create_directory_if_not_exists(config.AZURE_CREDENTIAL_CACHE_DIR)
  File
"/path-to/opt/pgadmin4/lib/python3.8/site-packages/pgadmin4/pgadmin/setup/data_directory.py",
line 20, in _create_directory_if_not_exists
os.mkdir(_path)
FileNotFoundError: [Errno 2] No such file or directory:
'/var/lib/pgadmin/azurecredentialcache'

My setup has absolutely nothing to do with Azure. I use python wheel having
PgAdmin installed in an unprivileged environment, so I am puzzled why it is
all of sudden trying to look for something in "/var/lib/pgadmin" or create
things there?

PG Admin 6.1 "flask" compatibility error upon install via python wheel

[Cherio]

When installing PGAdmin 6.1 via python wheel I got this error on Ubuntu
20.04, Python 3.8.10 (default, Sep 28 2021, 16:10:42) [GCC 9.3.0]

ERROR: flask 1.1.4 has requirement Jinja2<3.0,>=2.10.1, but you'll have
jinja2 3.0.2 which is incompatible.

Surprisingly pgAdmin4.py still runs and the application seems to be
functional on the surface. Should I be worried that the application may not
be 100% reliable because of that error?

Re: "Query Tool" is no longer available in a separate browser tab

[Cherio]

Ah, moved. Thank you!!! I should start wearing glasses.

On Mon, Mar 1, 2021 at 10:58 PM Aditya Toshniwal <
aditya.toshni...@enterprisedb.com> wrote:

> Hi Cherio,
>
>
>
> On Tue, Mar 2, 2021 at 2:10 AM Cherio  wrote:
>
>> Has the option to open "Query Tool" in a separate browser tab/window been
>> entirely removed? It was there in version 4.29. I upgraded to 5.0 and the
>> option is no longer there. Personally I am only using the query tool in a
>> separate tab as it gives significantly more visible real estate to work in.
>>
> No it's not removed. It will open a new window now.
> If you're looking for the setting, it has been moved to File ->
> Preferences -> Browser -> Tab settings -> Open in new browser tab with 4.30.
>
>>
>> I went through the release notes of several latest releases and saw no
>> mention of this feature being removed.
>>
>> So my question is whether this is a bug or it is a planned change?
>>
>> Thanks!
>>
>
>
> --
> Thanks,
> Aditya Toshniwal
> pgAdmin hacker | Sr. Software Engineer | *edbpostgres.com*
> <http://edbpostgres.com>
> "Don't Complain about Heat, Plant a TREE"
>

"Query Tool" is no longer available in a separate browser tab

[Cherio]

Has the option to open "Query Tool" in a separate browser tab/window been
entirely removed? It was there in version 4.29. I upgraded to 5.0 and the
option is no longer there. Personally I am only using the query tool in a
separate tab as it gives significantly more visible real estate to work in.

I went through the release notes of several latest releases and saw no
mention of this feature being removed.

So my question is whether this is a bug or it is a planned change?

Thanks!

Re: How do I remove this stupid "master password"?

[Cherio]

On the one hand angry emails like the one that started this thread reveal
how many of users don't realize they should be thankful and appreciative
they are given a free product to use. I personally was repelled by the
tone, but that's beyond the point.

On the other hand this specific question was raised  several times here
before.

In my mind it may not be a big lift to create a small [re]configuration
shell/python script that would take care of the most common settings like
this one. A simple command line "wizard" that simply asks to [re]define the
initial or existing configuration. This way the developers don't need to
worry about compromised security. I foresee variables like those below
(just a suggestion) to be a subject of such configuration script.

DATA_DIR
LOG_FILE
SQLITE_PATH
SESSION_DB_PATH
STORAGE_DIR
PGADMIN_INT_PORT
DEFAULT_SERVER_PORT
SERVER_MODE
MASTER_PASSWORD_REQUIRED


On Sun, Feb 28, 2021 at 6:08 PM richard coleman 
wrote:

> [ HOW TO DISABLE MASTER PASSWORD feature in pgAdmin4 ]
>
> Vladimir,
>
> I sympathize with you.  I have had some extensive discussions with the
> head developer, unfortunately it doesn't seem to be something that he is
> willing to address.  It's built to address a *remote* threat vector, one
> that the vast majority of users would not be susceptible to, nor would they
> agree that the minimal additional security provided warrants the lost time
> and inconvenience that having it entails.  Since he believes so strongly in
> this, it is set to a default of being on and not only is the setting *not*
> exposed in the configuration UI, but it makes use of a non-existent file in
> a location that typically only administrators have access to.  Since many
> (most) users who will be using this in desktop mode already have these
> permissions, all it does is force them to either; use a stupidly simple
> master password (a single space is sufficient), or research the
> byzantine instructions to create a config_local.py file with the magic
> line; "MASTER_PASSWORD_REQUIRED=False" .  It doesn't help that the official
> documentation located here
> https://www.pgadmin.org/docs/pgadmin4/5.0/config_py.html, gives a
> location for config_system.py.  It usually doesn't exist and more
> importantly is **not** the location where the config.py, config_distro.py,
> or the all important config_local.py (that you need to create to disable
> the MASTER PASSWORD feature) resides.  Of course, upgrading from pgAdmin4
> 4.x to pgAdmin4 5.0 re-enables the MASTER PASSWORD feature (⋋▂⋌).
>
> So, until the devs either; add the option to control the MASTER PASSWORD
> feature into the config UI where it belongs, or change things, here are the
> steps to disable it.
>
>1. Make sure pgAdmin4 is not running (if you are using pre-version 5,
>make sure it isn't running in the tray)
>2. Locate the pgadmin4 *config.py* file (it will be in a *web*
>sub-directory parallel to the directory containing the executable)
>3. Create a file named *config_local.py* in the same directory as the
>config.py file (you will probably need admin or equivalent permissions)
>4. Enter the line: MASTER_PASSWORD_REQUIRED=False into that file and
>save
>5. Start pgAdmin4 and enjoy your MASTER PASSWORD free life
>
> I hope that helps anyone else still struggling with this.
>
> rik.
>
> On Sun, Feb 28, 2021 at 5:47 AM Vladimir Nicolici 
> wrote:
>
>> Apparently, some parts of the message were lost when posting it through
>> postgresql-archive.org, so I attached a PDF version of my previous
>> message which includes the missing sections. Sorry about that.
>>
>>
>>
>> Sent from Mail  for
>> Windows 10
>>
>

Sort by DB size takes a very long time

[Cherio]

There seems to be a "suboptimal" implementation of the "Statistics" page
when it comes to sorting. I experienced it when sorting by DB "Size" field
but it looks like the problem to a lesser extent exists when sorting by
other fields as well.

Steps to reproduce:
1. Click on the "Databases" node; it should have multiple databases to work
2. Select "statistics" tab
3. Click to sort on the "Size" column

In my case it took about 40 seconds to sort 13 databases, including
"postgres" DB
[image: image.png]

Re: v4.26, produces no output, errors in the log

[Cherio]

After all my refreshes and re-installs it seems like Chrome browser issues
got on the way.
Apologies for the false alarm.

On Fri, Oct 9, 2020 at 1:56 AM Akshay Joshi 
wrote:

> Hi Cherio
>
> Have you execute the query or explain options (explain, explain analyze)?
> These options are available on the toolbar, I have tested explain is
> working fine for me on v4.26.
> If possible please provide the SQL Query and Screenshots.
>
> On Thu, Oct 8, 2020 at 11:25 PM Cherio  wrote:
>
>> After reinstalling 4.26, clearing everything again and restarting the
>> errors are gone, the data shows but the Explain tab is blank entirely.
>> Those sub-tabs underneath are missing so there is no explain data
>> whatsoever.
>>
>> The logs are clean.
>>
>> On Thu, Oct 8, 2020 at 1:29 PM Cherio  wrote:
>>
>>> I just upgraded pgAdmin from 4.24 to 4.26 (python wheel install) and
>>> almost all result tabs are now blank.
>>> Neither Query nor Explain produce any result. I cleared all chrome cache
>>> (cookies, session/local storage), restarted the backend with no success.
>>>
>>> I rolled back to 4.24 and everything works as before.
>>>
>>> Version: 4.26
>>> Copyright (C) 2013 - 2020, The pgAdmin Development Team
>>> Python Version: 3.8.2 (default, Jul 16 2020, 14:00:26) [GCC 9.3.0]
>>> Flask Version: 1.0.2
>>> Application Mode: Desktop
>>> Current User: pgadm...@pgadmin.org
>>> OS: "20.04.1 LTS (Focal Fossa)"
>>>
>>> The log is a repetition of the same error (see below)
>>>
>>>
>>> ===
>>> 2020-10-08 12:25:39,125: ERROR  flask.app:  400 Bad Request: The
>>> CSRF session token is missing.
>>> Traceback (most recent call last):
>>>   File
>>> "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
>>> line 256, in protect
>>> validate_csrf(self._get_csrf_token())
>>>   File
>>> "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
>>> line 94, in validate_csrf
>>> raise ValidationError('The CSRF session token is missing.')
>>> wtforms.validators.ValidationError: The CSRF session token is missing.
>>>
>>> During handling of the above exception, another exception occurred:
>>>
>>> Traceback (most recent call last):
>>>   File
>>> "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask/app.py", line
>>> 1811, in full_dispatch_request
>>> rv = self.preprocess_request()
>>>   File
>>> "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask/app.py", line
>>> 2087, in preprocess_request
>>> rv = func()
>>>   File
>>> "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
>>> line 224, in csrf_protect
>>> self.protect()
>>>   File
>>> "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
>>> line 259, in protect
>>> self._error_response(e.args[0])
>>>   File
>>> "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
>>> line 302, in _error_response
>>> raise CSRFError(reason)
>>> flask_wtf.csrf.CSRFError: 400 Bad Request: The CSRF session token is
>>> missing.
>>> 2020-10-08 13:01:37,714: ERROR  flask.app:  400 Bad Request: The
>>> CSRF session token is missing.
>>> Traceback (most recent call last):
>>>   File
>>> "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
>>> line 256, in protect
>>> validate_csrf(self._get_csrf_token())
>>>   File
>>> "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
>>> line 94, in validate_csrf
>>> raise ValidationError('The CSRF session token is missing.')
>>> wtforms.validators.ValidationError: The CSRF session token is missing.
>>>
>>> During handling of the above exception, another exception occurred:
>>>
>>> Traceback (most recent call last):
>>>   File
>>> "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask/app.py", line
>>> 1811, in full_dispatch_request
>>> rv = self.preprocess_request()
>>>   File
>>> "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask/app.py", line
>>> 2087, in preprocess_request
>>> rv = func()
>>>   File
>&g

Re: v4.26, produces no output, errors in the log

[Cherio]

After reinstalling 4.26, clearing everything again and restarting the
errors are gone, the data shows but the Explain tab is blank entirely.
Those sub-tabs underneath are missing so there is no explain data
whatsoever.

The logs are clean.

On Thu, Oct 8, 2020 at 1:29 PM Cherio  wrote:

> I just upgraded pgAdmin from 4.24 to 4.26 (python wheel install) and
> almost all result tabs are now blank.
> Neither Query nor Explain produce any result. I cleared all chrome cache
> (cookies, session/local storage), restarted the backend with no success.
>
> I rolled back to 4.24 and everything works as before.
>
> Version: 4.26
> Copyright (C) 2013 - 2020, The pgAdmin Development Team
> Python Version: 3.8.2 (default, Jul 16 2020, 14:00:26) [GCC 9.3.0]
> Flask Version: 1.0.2
> Application Mode: Desktop
> Current User: pgadm...@pgadmin.org
> OS: "20.04.1 LTS (Focal Fossa)"
>
> The log is a repetition of the same error (see below)
>
>
> ===
> 2020-10-08 12:25:39,125: ERROR  flask.app:  400 Bad Request: The CSRF
> session token is missing.
> Traceback (most recent call last):
>   File
> "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
> line 256, in protect
> validate_csrf(self._get_csrf_token())
>   File
> "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
> line 94, in validate_csrf
> raise ValidationError('The CSRF session token is missing.')
> wtforms.validators.ValidationError: The CSRF session token is missing.
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask/app.py",
> line 1811, in full_dispatch_request
> rv = self.preprocess_request()
>   File "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask/app.py",
> line 2087, in preprocess_request
> rv = func()
>   File
> "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
> line 224, in csrf_protect
> self.protect()
>   File
> "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
> line 259, in protect
> self._error_response(e.args[0])
>   File
> "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
> line 302, in _error_response
> raise CSRFError(reason)
> flask_wtf.csrf.CSRFError: 400 Bad Request: The CSRF session token is
> missing.
> 2020-10-08 13:01:37,714: ERROR  flask.app:  400 Bad Request: The CSRF
> session token is missing.
> Traceback (most recent call last):
>   File
> "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
> line 256, in protect
> validate_csrf(self._get_csrf_token())
>   File
> "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
> line 94, in validate_csrf
> raise ValidationError('The CSRF session token is missing.')
> wtforms.validators.ValidationError: The CSRF session token is missing.
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask/app.py",
> line 1811, in full_dispatch_request
> rv = self.preprocess_request()
>   File "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask/app.py",
> line 2087, in preprocess_request
> rv = func()
>   File
> "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
> line 224, in csrf_protect
> self.protect()
>   File
> "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
> line 259, in protect
> self._error_response(e.args[0])
>   File
> "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
> line 302, in _error_response
> raise CSRFError(reason)
> flask_wtf.csrf.CSRFError: 400 Bad Request: The CSRF session token is
> missing.
> 2020-10-08 13:01:42,712: ERROR  flask.app:  400 Bad Request: The CSRF
> session token is missing.
> Traceback (most recent call last):
>   File
> "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
> line 256, in protect
> validate_csrf(self._get_csrf_token())
>   File
> "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
> line 94, in validate_csrf
> raise ValidationError('The CSRF session token is missing.')
> wtforms.validators.ValidationError: The CSRF session token is missing.
>
> During handling of the above exception, another exception occurred:
>
> Traceback (mo

v4.26, produces no output, errors in the log

[Cherio]

I just upgraded pgAdmin from 4.24 to 4.26 (python wheel install) and almost
all result tabs are now blank.
Neither Query nor Explain produce any result. I cleared all chrome cache
(cookies, session/local storage), restarted the backend with no success.

I rolled back to 4.24 and everything works as before.

Version: 4.26
Copyright (C) 2013 - 2020, The pgAdmin Development Team
Python Version: 3.8.2 (default, Jul 16 2020, 14:00:26) [GCC 9.3.0]
Flask Version: 1.0.2
Application Mode: Desktop
Current User: pgadm...@pgadmin.org
OS: "20.04.1 LTS (Focal Fossa)"

The log is a repetition of the same error (see below)


===
2020-10-08 12:25:39,125: ERROR  flask.app:  400 Bad Request: The CSRF
session token is missing.
Traceback (most recent call last):
  File
"/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
line 256, in protect
validate_csrf(self._get_csrf_token())
  File
"/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
line 94, in validate_csrf
raise ValidationError('The CSRF session token is missing.')
wtforms.validators.ValidationError: The CSRF session token is missing.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask/app.py",
line 1811, in full_dispatch_request
rv = self.preprocess_request()
  File "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask/app.py",
line 2087, in preprocess_request
rv = func()
  File
"/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
line 224, in csrf_protect
self.protect()
  File
"/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
line 259, in protect
self._error_response(e.args[0])
  File
"/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
line 302, in _error_response
raise CSRFError(reason)
flask_wtf.csrf.CSRFError: 400 Bad Request: The CSRF session token is
missing.
2020-10-08 13:01:37,714: ERROR  flask.app:  400 Bad Request: The CSRF
session token is missing.
Traceback (most recent call last):
  File
"/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
line 256, in protect
validate_csrf(self._get_csrf_token())
  File
"/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
line 94, in validate_csrf
raise ValidationError('The CSRF session token is missing.')
wtforms.validators.ValidationError: The CSRF session token is missing.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask/app.py",
line 1811, in full_dispatch_request
rv = self.preprocess_request()
  File "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask/app.py",
line 2087, in preprocess_request
rv = func()
  File
"/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
line 224, in csrf_protect
self.protect()
  File
"/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
line 259, in protect
self._error_response(e.args[0])
  File
"/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
line 302, in _error_response
raise CSRFError(reason)
flask_wtf.csrf.CSRFError: 400 Bad Request: The CSRF session token is
missing.
2020-10-08 13:01:42,712: ERROR  flask.app:  400 Bad Request: The CSRF
session token is missing.
Traceback (most recent call last):
  File
"/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
line 256, in protect
validate_csrf(self._get_csrf_token())
  File
"/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
line 94, in validate_csrf
raise ValidationError('The CSRF session token is missing.')
wtforms.validators.ValidationError: The CSRF session token is missing.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask/app.py",
line 1811, in full_dispatch_request
rv = self.preprocess_request()
  File "/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask/app.py",
line 2087, in preprocess_request
rv = func()
  File
"/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
line 224, in csrf_protect
self.protect()
  File
"/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
line 259, in protect
self._error_response(e.args[0])
  File
"/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
line 302, in _error_response
raise CSRFError(reason)
flask_wtf.csrf.CSRFError: 400 Bad Request: The CSRF session token is
missing.
2020-10-08 13:01:44,035: ERROR  flask.app:  400 Bad Request: The CSRF
session token is missing.
Traceback (most recent call last):
  File
"/home/user/opt/pgadmin4/lib/python3.8/site-packages/flask_wtf/csrf.py",
line 

Re: pgAdmin 4 v4.26 released

[Cherio]

Dave,

Could you please confirm that the issue only affects the Windows install
and not the other ways of setting up pgAdmin.
My team is relying on the Python Wheel setup we run on Linux.

Thank you.

On Mon, Sep 21, 2020 at 6:09 AM Dave Page  wrote:

>
>
> On Sat, Sep 19, 2020 at 7:21 AM Dave Page  wrote:
>
>>
>>
>> On Sat, 19 Sep 2020 at 00:59, richard coleman <
>> rcoleman.ascen...@gmail.com> wrote:
>>
>>> Dave,
>>>
>>> Thanks for the update.  Are you going to rerelease the update with a
>>> valid certificate, or at least publish the SHA256 hash for the file so that
>>> we can verify that it downloaded correctly?
>>>
>>
>> Yes, a new release is in progress already.
>>
>
> I came to the conclusion that a new release isn't warranted, as there are
> no code changes, or any changes to the package contents at all; instead I
> have manually signed the original installers on the build server, and then
> re-pushed to the download site.
>
> Apologies for any inconvenience.
>
>
>>
>>
>>> Thanks again,
>>>
>>> rik.
>>>
>>> On Fri, Sep 18, 2020 at 4:45 AM Dave Page  wrote:
>>>
 Hi

 On Thu, Sep 17, 2020 at 4:22 PM Dave Page  wrote:

>
>
> On Thu, Sep 17, 2020 at 4:18 PM richard coleman <
> rcoleman.ascen...@gmail.com> wrote:
>
>> Akshay,
>>
>> Just downloaded pgadmin4-4.26-x64.exe from the official web site.
>> When I go to install it comes up with an "unknown publisher".
>>
>> Is this legit?
>>
>
> I'm seeing that too - there doesn't seem to be a digital signature on
> the installer.
>

 So to the original question, yes, it is legit. The certificate expired
 :-(


>
> I have to wonder a) how that happened without the build failing,
>

 That happened because all our build scripts will ignore certificate not
 found type errors, throwing out a warning to the (very long) build log
 instead. Microsoft's tools don't give a separate error for expired
 certificates - they have a generic "No suitable certificate found" one.

 It does it that way because individual developers don't have code
 signing certificates (they're expensive, a pain to get, and we don't want
 random ones with our name on them in existence, or to have lots of people
 with access to the one we use). Obviously the developers need to be able to
 build, even though they don't have a CSC.

 --
 Dave Page
 Blog: http://pgsnake.blogspot.com
 Twitter: @pgsnake

 EDB: http://www.enterprisedb.com




>>>
>>> --
>> --
>> Dave Page
>> https://pgsnake.blogspot.com
>>
>> EDB Postgres
>> https://www.enterprisedb.com
>>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EDB: http://www.enterprisedb.com
>
>

Re: What does this icon means?

[Cherio]

My interpretation is it is telling you which way to look.
Sorry :)

On Mon, May 4, 2020 at 10:17 AM Edson Richter 
wrote:

> A small arrow at table icon means what?
>
>
>
> Thanks,
>
> Edson
>

Re: Is pgadmin4 being developed at Microsoft?

[Cherio]

I hate to contribute to a non-constructive subject but sadly pgadmin 4
quality has plenty of room for improvement. I get that impression that
development strongly favors new features to stability making the product of
the kind of quality I can't trust. I have to wait for each release to be
tested by others and then cherry pick releases and jump selectively e.g.
from release 10 to 13 in order to avoid critical - in my ability to trust
it with my data - bugs. I can't think of another product in my daily use
that I trust less than PgAdmin which is kinda sad when I compare it with
e.g. PostgreSQL server almost rock-solid stability.

These were my 2 cents of useless rambling )))


On Mon, Oct 14, 2019 at 3:27 PM Alex Williams 
wrote:

> Because it sure seems like it. Every update to pgadmin4 breaks something.
> I continuously have to use it in a vm to revert back to a snapshot because
> either there's an issue with python or some other package and have to spend
> hours debugging why I can't get it to start.
>
> This is getting to be worse than Windows 10 updates.
>
> I had a working pgadmin4, forgot the specific version that was working
> (had to get rid of snapshots on one box to reduce space so I could shrink
> the vm) and now I get this after the latest update on Centos7
>
>
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/pgadmin4-web/pgAdmin4.py", line
> 97, in 
> app = create_app()
>   File
> "/usr/lib/python2.7/site-packages/pgadmin4-web/pgadmin/__init__.py", line
> 400, in create_app
> driver.init_app(app)
>   File
> "/usr/lib/python2.7/site-packages/pgadmin4-web/pgadmin/utils/driver/__init__.py",
> line 40, in init_app
> DriverRegistry.load_drivers()
>   File
> "/usr/lib/python2.7/site-packages/pgadmin4-web/pgadmin/utils/driver/registry.py",
> line 88, in load_drivers
> module = import_module(module_name)
>   File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in
> import_module
> __import__(name)
>   File
> "/usr/lib/python2.7/site-packages/pgadmin4-web/pgadmin/utils/driver/psycopg2/__init__.py",
> line 20, in 
> import psycopg2
>   File "/usr/lib64/python2.7/site-packages/psycopg2/__init__.py", line 50,
> in 
> from psycopg2._psycopg import ( # noqa
> ImportError: /usr/lib64/python2.7/site-packages/psycopg2/_psycopg.so:
> undefined symbol: PQencryptPasswordConn
>
>
>
>
> Sent with ProtonMail  Secure Email.
>
>

Re: Forcing "quotes" around Value field in database Parameters sheet

[Cherio]

Looks like a regression. This works correctly in 4.10 which is a relatively
good release.

I am waiting for a release stable enough to upgrade from 4.10. If this is
the only regression in 4.13 I might do that

On Fri, Sep 20, 2019 at 4:16 AM Milan Oparnica  wrote:

> Thanks Akshay, done.
>
> Issue #4760  created.
>
> :)
> On 20.9.19. 09:23, Akshay Joshi wrote:
>
> Hi Milan
>
> Please log this issue @ https://redmine.postgresql.org/projects/pgadmin4.
>
> On Thu, Sep 19, 2019 at 4:44 PM Milan Oparnica 
> wrote:
>
>> Hi good people  :)
>>
>> I may have found a bug in the *Database properties* sheet preventing
>> setting *Parameters* on the database level.
>>
>> I tried to set the *search_path* parameter on the database level.
>>
>>1. Right click on the database
>>2. Select *Properties...* from the menu
>>3. Click on tab *Parameters*
>>4. Click *+* and enter *search_path* to *Name* field
>>5. Enter *scha, schb, public, pg_catalog *in the *Value *field (note,
>>without quotes)
>>6. Click *Save*
>>
>> Run new query window and type *show search_path*. The result is *"**scha,
>> schb, public, pg_catalog"* - together with the quotes aroud the string.
>> Such path, of course, is not valid.
>>
>> Testing this in the same query window:
>>
>> *SET search_path TO scha, schb, public, pg_catalog*;
>>
>> *SHOW search_path*
>>
>> results with
>>
>> *scha, schb, public, pg_catalog* (without quotes, and it works as
>> expected).
>>
>> My conclusion is that pgAdmin4 for some reason adds and stores quotes
>> around the search_path value, and later uses the value as if it is a *single
>> full path name*.
>>
>> The database server this occures on is Pg 11.
>>
>> Best regards,
>>
>> M.O.
>>
>
>
> --
> *Thanks & Regards*
> *Akshay Joshi*
>
> *Sr. Software Architect *
> *EnterpriseDB Software India Private Limited*
> *Mobile: +91 976-788-8246*
>
>

Re: pgadmin 4 feature behavior change requests

[Cherio]

>
> 2. Have a sql query check button (unless I'm mistaken, I don't see it)
> where it will check if your sql syntax is correct, but wont execute it.
>

I personally use "Analyze" for that purpose. It seems to be doing exactly
that

Re: pgAdmin4 4.8 Kubuntu issues

[Cherio]

File location (assuming you have python 3.5) is
"lib/python3.5/site-packages/pgadmin4/config_local.py" relative to the
pgadmin install directory. You may have to create it as the file is
optional. You use it when you need to override default configuration. I
like to keep pgadmin 4 configuration separate from pgadmin3 so mine looks
like this

$> cat ./opt/pgadmin4/lib/python3.5/site-packages/pgadmin4/config_local.py
import os
DATA_DIR = os.path.realpath(os.path.expanduser(u'~/.pgadmin-v4/'))
LOG_FILE = os.path.join(DATA_DIR, 'pgadmin4.log')
SQLITE_PATH = os.path.join(DATA_DIR, 'pgadmin4.db')
SESSION_DB_PATH = os.path.join(DATA_DIR, 'sessions')
STORAGE_DIR = os.path.join(DATA_DIR, 'storage')
SERVER_MODE = False
MASTER_PASSWORD_REQUIRED = False


On Wed, Jun 5, 2019 at 9:44 AM richard coleman 
wrote:

> Dave,
>
> Sorry, but after an e*xhaustive* search of the several terabytes on my
> machine, there is *no* config_local.py file.  Do you have any idea where
> it's supposed to be located?
>
> Thanks,
>
> rik.
>
> On Wed, Jun 5, 2019 at 9:30 AM Dave Page  wrote:
>
>>
>>
>> On Wed, Jun 5, 2019 at 1:16 PM richard coleman <
>> rcoleman.ascen...@gmail.com> wrote:
>>
>>> Cherio,
>>>
>>> I am sorry to inform you, but there is *no* mention of "config_local.py"
>>> on that page, nor any indication of where I would find it.
>>>
>>
>>
>> https://www.pgadmin.org/docs/pgadmin4/4.x/desktop_deployment.html#configuration
>>
>>
>>>
>>> rik.
>>>
>>> On Tue, Jun 4, 2019 at 5:06 PM Cherio  wrote:
>>>
>>>> Put "MASTER_PASSWORD_REQUIRED = False" line into your
>>>> "lib/python?.?/site-packages/pgadmin4/config_local.py". This is in the
>>>> docs: https://www.pgadmin.org/docs/pgadmin4/dev/master_password.html
>>>>
>>>> On Tue, Jun 4, 2019 at 4:41 PM richard coleman <
>>>> rcoleman.ascen...@gmail.com> wrote:
>>>>
>>>>> To whomever,
>>>>>
>>>>> Running a newly update pgAdmin 4 version 4.8 on my Kubuntu box.  There
>>>>> are a couple of glaring issues.
>>>>>
>>>>> First: It keeps prompting to; "Set Master Password"
>>>>> I don't want to set another password that I'll just end up
>>>>> forgetting.
>>>>>
>>>>> Second: When I click the "?" button on that dialog box it takes me to
>>>>> this page:
>>>>> "http://127.0.0.1:33681/help/help/master_password.html;
>>>>> Which returns "404 Not Found"
>>>>>
>>>>> Hopefully there is a simple solution to these issues.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> rik.
>>>>>
>>>>
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>

Re: pgAdmin4 4.8 Kubuntu issues

[Cherio]

Put "MASTER_PASSWORD_REQUIRED = False" line into your
"lib/python?.?/site-packages/pgadmin4/config_local.py". This is in the
docs: https://www.pgadmin.org/docs/pgadmin4/dev/master_password.html

On Tue, Jun 4, 2019 at 4:41 PM richard coleman 
wrote:

> To whomever,
>
> Running a newly update pgAdmin 4 version 4.8 on my Kubuntu box.  There are
> a couple of glaring issues.
>
> First: It keeps prompting to; "Set Master Password"
> I don't want to set another password that I'll just end up forgetting.
>
> Second: When I click the "?" button on that dialog box it takes me to this
> page:
> "http://127.0.0.1:33681/help/help/master_password.html;
> Which returns "404 Not Found"
>
> Hopefully there is a simple solution to these issues.
>
> Thanks,
>
> rik.
>

Re: pgAdmin v4.7

[Cherio]

And this is how I delay installing new releases of PgAdmin 4 one after
another. While a release fixes one issue it introduces another. The number
of unreliable PgAdmin 4 releases is quite high.

On Fri, May 31, 2019 at 6:47 AM Fahar Abbas 
wrote:

> Hi,
>
> We have already fixed the issue and will be available in next 4.8 release.
>
> On Fri, May 31, 2019 at 12:10 AM Fahar Abbas 
> wrote:
>
>> Hi Michelle,
>>
>> This is a valid issue and reproducible on my end and Here is RM ID:
>> https://redmine.postgresql.org/issues/4309
>>
>>
>>
>>
>> On Thu, May 30, 2019 at 10:30 PM Michelle Schwan 
>> wrote:
>>
>>> Just installed pgAdmin v4.7 from v4.6 with no issues.
>>>
>>>
>>>
>>> I found a bug.
>>>
>>>
>>>
>>> Go to Views and select SQL.  Click on a view and receive an error
>>> message.  This was not happening in v4.6.
>>>
>>>
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Michelle
>>>
>>>
>>>
>>
>>
>> --
>> Fahar Abbas
>> QMG
>> EnterpriseDB Corporation
>> Phone Office: +92-51-835-8874
>> Phone Direct: +92-51-8466803
>> Mobile: +92-333-5409707
>> Skype ID: *live:fahar.abbas*
>> Website: www.enterprisedb.com
>>
>
>
> --
> Fahar Abbas
> QMG
> EnterpriseDB Corporation
> Phone Office: +92-51-835-8874
> Phone Direct: +92-51-8466803
> Mobile: +92-333-5409707
> Skype ID: *live:fahar.abbas*
> Website: www.enterprisedb.com
>

Re: pgAdmin 4.3 scratch pad

[Cherio]

This would be a great option to have. Scratchpad can be a nuisance
especially due to resizing bug. For some reason nomatter how you resize
results panel scratchpad grows in size.

On Tue, Mar 19, 2019 at 11:36 AM richard coleman <
rcoleman.ascen...@gmail.com> wrote:

> Hi All,
>
> Is there a setting to *stop* the scratch pad from showing up *every time *you
> open a query window?
>
> pgAdmin 4.3, Kubuntu 18.10, Chromium
>
> Thanks,
>
> rik.
>

Editing boolean table value from keyboard

[Cherio]

When I right click on a table and select "View/Edit Data" I can edit fields
from keyboard with the exception of boolean fields. There seem to be no key
that could toggle boolean values. It is currently only possible by using
mouse.

This breaks the flow a bit. My usual routine is to start with the first
field, type in the value then hit "Tab". It goes to the next field. Repeat.
For boolean fields however I have to go back and grab mouse.

I think a key (e.g. "Space") should be assigned to scroll through
"true"/"false"/NULL via keyboard.

Am I missing something and such a key or key combination is already
assigned or can be configured?

Thanks!

Re: F5 reloading page in 3.5

[Cherio]

I also run it in Chrome/XFCE and this has been a bug since the beginning of
v4. I ended up simply remapping all actions based on F5. I use F7/F8 to run
plan/query.

I noticed that from time to time query edit box out of the blue loses focus
e.g. as I type SELECT  it stops typing and I discover that focus is
no longer on that input area. This may be related to F5 issue. When the
element that is supposed to listen to events is no longer receiving events
the keyboard keys it intercepts will be processed by the browser with its
default handlers.

This is just a speculation but it would explain both issues.

Loss of focus could be also caused by Chrome extensions, spellchecker, etc
though this never happened to me in e.g. gmail or google docs or any other
web app so I am inclined to think this is a pgadmin bug.

On Sat, Nov 24, 2018 at 3:37 PM Richard Greenwood <
richard.greenw...@gmail.com> wrote:

> I use F5 to execute queries. In previous versions of pgAdmin4 if F5 was
> going to reload the page a warning message allowed you to cancel the page
> reload, and thus save your work, reduce (slightly) frustration, etc. But in
> 3.5 that seems to be gone. I'm running current Chrome in Ubuntu.
>
> Rich
> --
> Richard W. Greenwood, PLS
> www.greenwoodmap.com
>

Re: Is there any way to get pgadmin4-v3 to work on a non-gnome linux platform

[Cherio]

It has no issues running in xfce. I did a standard python wheel set up on 2
xfce workstations. It runs in Chrome well. As often happens it had issues
converting configuration from the previous version but has no issues
specific to graphic environment.

On Wed, Jun 6, 2018 at 6:15 AM Raymond O'Donnell  wrote:

> On 06/06/18 06:08, Darren Duncan wrote:
> > On 2018-06-05 11:05 AM, Mike Martin wrote:
> >> Hi
> >> I have hit a brick wall trying to run pgadmin4-v3 on my Linux box
> >> running xfce. It insists on a gnome-specific chrome/firefox extension,
> >> which then insists on a running copy of gnome shell
> >
> > That seems strange to me.  I thought PgAdmin4-v3 ran in stock web
> > browsers without needing any browser extensions. -- Darren Duncan
>
> I run it in Firefox 60 on KDE (Debian 8) without any extensions.
>
> Ray.
>
> --
> Raymond O'Donnell :: Galway :: Ireland
> r...@iol.ie
>
>

Re: pgadmin4.3 - login failure

[Cherio]

Please take a look at the issue I filed a few days ago labelled "v4 3.0
connection issues, notices is readonly", it is related
https://www.postgresql.org/message-id/CAKHqFkK%3DAm5JBrdxmaFW92PQAf0m5QNsT2TGj7EJ2fBRgfAHrA%40mail.gmail.com

On Fri, Apr 20, 2018 at 7:59 AM frankgard <
frank.von.postgresql@familie-gard.de> wrote:

> Hi Tony,
>
> according to  this Stackoverflow post
> <
> https://stackoverflow.com/questions/49919149/unable-to-connect-to-postgresql-with-pgadmin4-readonly-attribute-error>
>
> , the error seems to be caused by a too old psycopg2 library. Perhaps you
> can upgrade to v2.7, or just comment out line 313 of
> /usr/share/pgadmin4/web/pgadmin/utils/driver/psycopg2/connection.py as some
> kind of "dirty hack", but be aware that I don't know the "deeper
> consequences" of doing so.
>
> Hope this helps.
>
> Cheers,
> Frank.
>
>
>
> --
> Sent from:
> http://www.postgresql-archive.org/PostgreSQL-pgadmin-support-f2191615.html
>
>

Re: Desktop-mode on Debian

[Cherio]

Johann,

I run XFCE4 with cairo dock, but I also have a panel at the top with the
indicator plugin and the elephant icon shows up there whenever I start
pgadmin4. The icon works but not scalable, like the other icons and since
my panel size is smaller than default (18 px) the elephant is a bit cropped
from both top and bottom.

On Wed, Apr 18, 2018 at 4:05 AM Johann Spies  wrote:

> Hallo Christoph,
>
> Thanks for your answer.
> On Wed, Apr 18, 2018 at 09:28:17AM +0200, Christoph Berg wrote:
>
> > pgadmin4 3.0's desktop mode is running an application in the
> > background, and accessing it using your web browser. If you don't want
> > it to use your default browser, right-click on the elephant in the
> > systray, and configure a different command.
> >
> > (With 2.x it technically did the same, just that the web browser was
> > bundled inside the pgadmin4 binary.)
>
> I am running XFCE4 with an additional Cairo-dock panel and nowhere can I
> find the pgadmin4-elephant in any systray.
>
> Until I can figure this out, I will use a combination of pgadmin3,
> datagrip and omnidb-app.
>
> Regards
> Johann
> --
> Johann SpiesTelefoon: 021-808 4699
> Databestuurder /  Data manager  Faks: 021-883 3691
>
> Sentrum vir Navorsing oor Evaluasie, Wetenskap en Tegnologie
> Centre for Research on Evaluation, Science and Technology
> Universiteit Stellenbosch.
>
> The integrity and confidentiality of this e-mail is governed by these
> terms / Die integriteit en vertroulikheid van hierdie e-pos word deur die
> volgende bepalings gereël. http://www.sun.ac.za/emaildisclaimer
>
>

v4 3.0 connection issues, notices is readonly

[Cherio]

Hello,

PgAdmin 4 v3.0 didn't work out of the box on my ubuntu 16.04.4. Both DEB
install and python wheel generate errors. I researched the DEB install and
determined that the error occurs in
"/usr/share/pgadmin4/web/pgadmin/utils/driver/psycopg2/connection.py" on
line 313 which reads

pg_conn.notices = deque([], self.ASYNC_NOTICE_MAXLENGTH)

and complains that the property is readonly. I am not a python guy but
after some research I made the following tweak to make it work:

if self.async == 1:
pg_conn.notices = deque([], self.ASYNC_NOTICE_MAXLENGTH)

The same file has similar code on line ~1250 though I didn't see errors on
that line.

Another error which completely prevents from continuing on a web page is
the "INTERNAL SERVER ERROR" which locks the screen with an alert popup (the
title reads "AlertifyJS") that can't be closed, but I believe this was
already reported and claimed to be fixed the next day.

Regards,
Yuri