galaxy

Насколько я помню из предыдущего вопроса вашего, вы коннектитесь к БД postgres (jdbc:postgresql://localhost:5432/postgres - последний член здесь означает название БД), а надо к Drive_in.

jdbc:postgresql://localhost:5432/Drive_in

jdbc:postgresql://..... ?

172.17.0.1 - непубличный адрес, как это вы к нему с домашнего компа подключаетесь?
Проверяйте, на каких адресах висит сервер postgres'а.

SELECT *
  FROM TABLE
 WHERE id IN (1,2,3);

Куда добавить этот запрос?

В транзакцию.

BEGIN;
INSERT ...;
UPDATE ...;
COMMIT;

LEFT JOIN делается так:

...
LEFT JOIN "readed_news" "rn" 
ON ("rn"."newsId" = "news"."id" )
...

Тогда, если в таблице связи readed_news новости нет, в колонке rn.newsId будет NULL (можно добавить в WHERE: AND rn.newsId IS NULL).
Или обойдитесь без джойна и сделайте в WHERE:

...
AND id NOT IN (
  SELECT newsId FROM readed_news WHERE userId = 5
)

(под капотом, конечно, все равно будет джойн).

...
where date_from between  '2020-11-23'::date  and '2020-11-29'::date 
   and date_to  between  '2020-11-23'::date  and '2020-11-29'::date

UPDATE SET name = $2, avatar = $3 WHERE users.steamid = $1;

created_at и кстати какой лучше выбрать тип для хранения времени если время хранится в стиле 1606208106781

А чего бы время не хранить в специально созданном для него типе timestamp (даже timestamptz)?
Если очень хочется числом, то, видимо, BIGINT.

books и вот тут должен быть список книг пользователя их количество может быть от 0 до 100

Это вообще-то денормализация, которую не жалуют теоретики SQL и не очень любят ORM'ы. Подумайте, точно ли она вам нужна, т.к. большинство решений будет еще и плохо переносимо с одной СУБД на другую.
А так конкретно для postgres лучше всего колонку book сделать типа int[] (массив int). Можно и строкой, и хранить id через запятую там, но это уже какие-то лишние телодвижения.

как сделать так чтобы делая запрос чтобы получить информацию о пользователе я еще получал информацию еще о книгах

Сделать несложно, но будет дублирование данных. Например:

SELECT u.*, b.*
  FROM users u
  LEFT JOIN books b ON (b.id = ANY(u.books))
 WHERE ...

Выдаст что-то типа:

name    | surname  | balance | created_at       | books     | id    | title             | author
______________________________________________________________________________________________________________
Alex    | Smith    | 22.10   | 1606349583252    | {2,10,88} | 2     | A Game of Thrones | George R. R. Martin
Alex    | Smith    | 22.10   | 1606349583252    | {2,10,88} | 10    | A Clash of Kings  | George R. R. Martin
Alex    | Smith    | 22.10   | 1606349583252    | {2,10,88} | 88    | A Storm of Swords | George R. R. Martin

В постгресе права выдаются на конкретный типа объекта (database, schema, table, sequence, etc.) и зависят от этого типа. При этом выданные права на родительский объект не означают наличие каких-либо прав на дочерние объекты.
Вы выдали юзеру все права на DATABASE, это означает, что он может к ней коннектиться и создавать в ней схемы, публикации и временные таблицы. Всё.
Таблицу example вы создаете под другим пользователем, botuser никаких прав на нее не имеет.
https://postgrespro.ru/docs/postgresql/13/ddl-priv

pg_dump с ключом -t

В общем случае не существует: вы, исходя из формулировки вопроса, хотите получать доступ к произвольным записям и суммировать произвольные колонки.

Если несколько уменьшить степень гибкости, можно преагрегировать данные для последующей аналитики (можно сказать, создать ряд materialized view). Чтобы было понятнее, пусть имеется сырая таблица продаж (я намеренно делаю ее денормализованной, в реальности это может быть несколько таблиц, которые соединяются в запросе):

sales
------------------
datetime
client_first_name
client_last_name
client_email
client_region
client_city
client_age
client_gender
product_name
product_category
product_type
product_manufacturer
product_price
quantity
shop_id
shop_region
shop_city
seller_first_name
seller_last_name
seller_department
...

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

SELECT client_region, client_gender, client_age, product_category, product_type, shop_id, SUM(quantity), SUM(product_price*quantity)
  FROM sales
 GROUP BY client_region, client_gender, client_age, product_category, product_type, shop_id

Также, если вы не собираетесь фильтровать по времени с точностью до секунды, а делаете отчеты максимум по дням, по полю datetime также можно сделать группировку (GROUP BY date_trunc('day', datetime)).

Чтобы не плодить кучу таблиц, можно организовать такое хранилище (обычно его называют Data warehouse) по схеме звезды.

Ну соберите обратно в массив

select array_agg(v)
  from (select jsonb_array_elements(col)->'a' v
	  from (values ('[{"a": 1, "b": 2}, {"a": 10, "b": 20}]'::jsonb)) as t(col)
	) t1

SELECT SUM (CASE WHEN status = 1 THEN amount END) as sum1, ... FROM ... GROUP BY ..