pgadmin 4 3.1 панель вывода данных с закрытием

В инструменте запросов при попытке повысить или уменьшить границу между Query Sql Editor и панелью вывода данных очень часто бывает, что когда вы перемещаете мышь над заголовком панели Data Output, она меняет значок вертикальной стрелки на стрелку вправо Панель вывода данных от плитки по умолчанию до плавающей

Что мне следует сделать, чтобы вернуть панель вывода данных в исходный режим черепицы?

Кроме того, панель Data Output один раз в плавающем окне перестает показывать результаты запросов, она отображает только сообщения, я предполагаю, что это ошибка 3.1.

Мое решение до сих пор заключается в том, чтобы сохранить запрос, закрыть его и снова открыть, чтобы восстановить режим черепицы

Проблемы исчезновения курсора не были полностью исправлены

Каков лучший свободный конкурент pgadmin 4?

заранее спасибо

Ответ 1

В браузере pgadmin щелкните меню файлов и выберите сброс макета.

Ypu получит все виды предупреждений, но инструмент запросов снова станет полезным.

Ответ 2

Я не знаю в PgAdmin 4.3, но в 4.6 я нашел способ перестроить его.

Во-первых, щелкните правой кнопкой мыши где-нибудь, чтобы сначала добавить панель → Скретч-панель, чтобы сначала получить держатель панели (при нажатии обратите внимание на выделенный светло-голубой пробел),

затем щелкните правой кнопкой мыши нижнюю половину пространства, чтобы добавить другую панель → Блокнот в нижней половине пространства (при нажатии обратите внимание на выделенный светло-голубой пробел) ,.

После этого нажмите на вкладку и удерживайте, чтобы перетащить туда, куда вы хотите (при нажатии обратите внимание на выделенный светло-голубой пробел).

Ответ 3

Нет, это не ошибка, эти панели предназначены для плавания, чтобы пользователь мог организовать представление в соответствии с их убеждением.

Но да, у пользователя должна быть возможность заблокировать макет, и я вижу, что запрос функции блокировки макета уже находится в списке pgadmin4. Надеюсь, мы получим его в следующем выпуске будущего. Ссылка: https://redmine.postgresql.org/issues/3155