Михаил

Храните пароль в файле pgpass
С vaccumdb не пробовал, но psql его оттуда отлично подхватывает.

https://www.postgresql.org/docs/current/libpq-pgpa...

Зачем так сложно?

В БД делаем поля
status - статус таска (NEW, COMPLETED)
assignee - исполнитель
scheduled - дата до которой исполнитель должен предоставить результат.

Когда выбираем список задач для взятия - используем условие

(status = NEW) AND (assignee IS NULL /*не назначена*/ OR scheduled < NOW() /*истекла*/)

Когда пользователь пытается сохранить результат - проверяем что исполнитель он и что таска не истекла. Если условие не выполнено - не даем сохранить.

И никаких демонов, тем более каждую секунду.

Это определяется бизнес-логикой приложения.

Например, если у вас возникает ошибка дублирования уникального ключа - нужно ли откатывать всю транзакцию? Или приложение сможет восстановиться и продолжить работу?

Обернуть потенциально чреватый ошибками код в try-catch - всегда хорошая идея, если у вас есть план как восстанавливаться после ошибки (записать в лог/отправить уведомление/вывести ошибку и продолжить работу - вполне адекватное поведение)

SELECT * FROM "Couriers";

Если название таблицы/поля и пр. объектов в постгресе содержит заглавные буквы - его надлежит брать в кавычки. Поэтому, во избежание лишних проблем, заглавные обычно избегают.

Если под пустой строкой подразумевается NULL - то COALESCE
Если под пустой строкой подразумевается "" - то CASE

Можно через JOIN:

SELECT t2.* FROM t t1 JOIN t t2 ON t1.input_id = t2.input_id
WHERE t1.id=1

Пример

Достаете из БД экземпляр класса Information, остальные зависимости Hibernate вытащит сам, если они корректно описаны.

Записывайте в БД дату и время возврата кредита. А при выводе данных пользователю - вычисляйте остаток времени.

Если вас интересует это в плане получаемого результата - то да, можно рассматривать это так: декартово произведение + фильтр строк по условию (и добавление NULL-ов в случае LEFT JOIN).

Если интересует как это устроено внутри СУБД - то там далеко не всегда будет декартово произведение, потому что это довольно затратная операция. Какие конкретно операции будет выполнять СУБД можно увидеть по EXPLAIN-у - это называется план запроса. Там может быть и NESTED LOOP (вложенный цикл) и MERGE JOIN и другие операции, которые планировщик запроса сочтет подходящими для данного конкретного сочетания таблиц в данном конкретном запросе (на это влияет структура запроса, наличие индексов, собранная по таблицам статистика и пр. факторы, углубляться в которые я сейчас не буду).

Нужно указать сортировку в оконной функции. А ORDER BY запроса тогда можно делать по полю num.

SELECT u.id, u.avatar_path, u.rating, ROW_NUMBER() OVER (ORDER BY u.rating DESC) AS num
FROM users AS u
ORDER BY num ASC;

SELECT SUM(confirmed_ones) AS confirmed_ones, SUM(rejected_ones) AS rejected_ones FROM (
  SELECT ... /*тут ваш запрос из вопроса */
)

Эспортируете данные в SQL (см. mysqldump, pg_dump). На целевой системе - загружаете полученный SQL.

В Postgresql нет автоинкремента, в postgresql есть последовательности (sequence).
Собственно берите значение (nextval) из одного и того же сиквенса при вставке записи в обе таблицы - получите то что вам нужно.

Вообще, если говорить о деньгах, то крайне маловероятно что у вас будут доли копеек (центов и т.п.). Поэтому, можно хранить денежные суммы в виде пары "целое число" (long) + "код валюты" (целое или строка, код валюты ISO). К этой структуре, тогда, нужно иметь справочник валют, в котором будет точность валюты т.е. множитель для перевода из рублей в копейки, из долларов в центы, из евро в евроценты (1 к 100). А, например, у юаня этот множитель будет 1, так как эти денежные единицы не делятся на доли. У биткоина этот множитель будет 10^8 (сатоши).

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