Сделать снапшот виртуалки и развернуть на другом гипере)

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

SELECT
        CASE WHEN point = 'url' THEN uri END AS url,
        CASE WHEN point = 'test' THEN uri END AS urn
INTO set_url, set_uri FROM map_api.api_uri;

SELECT
        CASE WHEN point = 'url' THEN uri END AS url,
        CASE WHEN point = 'test' THEN uri END AS urn
INTO set_url, set_uri FROM map_api.api_uri;

А куда их выдавать-то? Эти set_url, set_uri — это же скалярные переменные.
Или в чём вопрос?

в том что выдаёт null при любом другом значении point, отличающемся от url (первая строка в таблице)

Ну так и должен же.
CASE WHEN ... THEN x END = CASE WHEN ... THEN x ELSE NULL END

и как это должно объяснять получение null ?

Привет. В этой статье https://habr.com/ru/post/314048/ автор пишет: "Не используйте схему public". Насколько распространена такая практика?

у меня она выпилена

можно просто сделать

REVOKE ALL ON SCHEMA public FROM public;

и не создавать суперпользователей

Приветствую. Помогите пожалуйста, не показываются данные о таблице

pager

спасибо огромное!!!

^)

>Никогда не используйте конструкции вида
>select myfunc() from table;

>Время выполнения такого запроса возрастает в линейной зависимости от количества строк. Такой запрос всегда можно переписать в нечто без функции, применяемой к каждой строке, и выиграть >пару порядков в скорости выполнения.

Вот это не понятно. если нужна какая то валидация, форматирование или еще какая-то обработка значения, чем это плохо,
наоборот код в одном месте легко контролировать?

>Если ваш запрос работает медленно на тестовом компьютере, то в продакшене он работать быстрее не будет.

Это вообще спорно.

>Никогда нельзя перенаправлять пользователя приложения через сервер в базу данных, взаимно-однозначно транслируя пользователя приложения в пользователя БД. Даже если вам кажется, что при этом можно настроить в БД безопасность для пользователей и их групп штатными средствами PostreSQL, никогда не делайте так, это ловушка! При такой схеме нельзя использовать пулы соединений, и каждый подключенный пользователь приложения будет отъедать ресурсоемкое соединение к базе данных.

так же при определенных вводных вполне рабочая вещь.

Там вообще очень узкий кейс работы с базой рассматривается. Автор априори считает что базу используют не только как хранилище денных, но и как контейнер для логики (что далеко не всегда так). Например если логики нету, то паблик вполне можно использовать.

Автор так-же не рассматривает вариант когда схемы просто не нужны (а они в 90% случаев не нужны)

Привет
Как смотрите на такое ?
SELECT unnest(array[1,3,4]) EXCEPT SELECT unnest(array[1,3]);
Дошёл до этого при задаче удаления элементов массива b (1,3) из массива  a (1,3,4)

См. https://wiki.postgresql.org/wiki/A_Guide_to_CVE-2018-1058:_Protect_Your_Search_Path
И, соответственно, в документации это описано тоже.

Эээ... тривиально? ;) Или Вы просто не можете объяснить, в чём у Вас проблема?

Спасибо