Akina

Нужно каждое слово оборачивать в %?

Нет. Вернее, этого недостаточно.
Условие WHERE name LIKE '%сок%перс%', конечно, не пропустит указанные нежелательные записи - но и "Персиковый сок" тоже будет отброшен.

Нужно проверять наличие каждого слова отдельно.

SELECT *
FROM table
WHERE name LIKE '%сок%'
  AND name LIKE '%перс%';

SELECT test.id, SUM(jsontable.price) total_price
FROM test
CROSS JOIN JSON_TABLE(test.data,
                      '$.products[*]' COLUMNS (price INT PATH '$.price')) jsontable
GROUP BY test.id

fiddle

SELECT *
FROM tablename
WHERE data < CURRENT_DATE + INTERVAL 5 DAY
-- AND data >= CURRENT_DATE

$db->prepare("SELECT comments.id, ... , users.login
                   , :me AS me 
              FROM `comments` ... ");
    $comments->execute([
    "id_post" => $dataAttr,
    "me" => $_SESSION["user"]["id_user"],
    ]);

или типа того...

CREATE OR REPLACE FUNCTION _Foo2(st TIMESTAMP, fin TIMESTAMP)
RETURNS TABLE (out_key INTEGER, out_tst timestamptz, out_val FLOAT) AS $$
DECLARE  
  
BEGIN

  RETURN QUERY EXECUTE FORMAT('
  SELECT %I, %I, %I
  FROM %I 
  WHERE %I BETWEEN ''%s'' AND ''%s'';
  ', 
  'in_key', 'in_tst', 'in_val', 'in_table', 'in_tst', st, fin);

END;

$$ LANGUAGE plpgsql;

DEMO fiddle

Ошибки найдёте самостоятельно...

INSERT INTO может привести к ошибке. По любой причине. При этом процесс вставки прерывается, а все уже внесённые в таблицы изменения - откатываются.

INSERT IGNORE преобразует ошибку в предупреждение. При этом выполнение запроса продолжается, а запись, попытка вставки которой привела к ошибке, не вставляется.

Замечание. Дублирование - не единственное событие, которое может вызвать ошибку. Может быть ещё куча причин (CHECK constraint, SIGNAL из триггера, нарушение внешнего ключа и т.п.). Причём далеко не все типы ошибок восстановимы и могут быть проигнорированы/преобразованы в предупреждение. Если ошибка невосстановимая (как правило, это системные или внешние ошибки) - запрос прерывается по ошибке и откатывается обычным образом.

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

Нужно игнорировать дублирующиеся данные. Буду делать INSERT IGNORE

Кроме INSERT IGNORE INTO есть ещё два типа запросов, которые обрабатывают ошибку дублирования данных - это INSERT .. ON DUPLICATE KEY UPDATE и REPLACE INTO. Изучите их - возможно, какой-то из них лучше подходит для Вашей конкретной задачи. При этом REPLACE не поддерживает модификатор IGNORE и не может игнорировать другие ошибки.

В OpenServer -> PHPMyAdmin я создал юзера root1

Мало создать юзера, надо ещё дать ему необходимые для работы права. Хотя бы элементарно на чтение для той БД, которая указана как база по умолчанию.

Вот параметры юзера

Право USAGE - это синоним права “no privileges”. Т.е. свежесозданный юзер - абсолютно бесправен.

Читайте и применяйте GRANT Statement. Особое внимание обратить на WITH GRANT OPTION.

Надо подсчитать количество строк в ответе запроса вида

Вариантов несколько.

Первый, наиболее правильный - получить это значение отдельным запросом.

SELECT COUNT(*)  AS cnt
FROM (
    SELECT 1
    FROM "order" AS o
         LEFT JOIN product p ON (p.order_id = o.id)
    GROUP BY o.id
    HAVING sum(p.price) >= 10
) x

Второй - используя средства языка программирования или библиотеки доступа, получить количество записей в наборе записей. Обычно подобное свойство у рекордсета присутствует.

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

SELECT o.id, COUNT(o.id) OVER () AS cnt
FROM "order" AS o
         LEFT JOIN product p ON (p.order_id = o.id)
GROUP BY o.id
HAVING sum(p.price) >= 10

Как отработает этот запрос?
внутренний sum посчитает сумму в рамках групп бай, если ins_date равна cur_date, а потом внешний sum суммирует полученный результат в контексте секций?

Именно так и будет. Считай, что оконные функции работают после HAVING и перед ORDER BY.

https://www.postgresql.org/docs/current/functions-...

Операторы @> и <@

https://dbfiddle.uk/?rdbms=postgres_12&fiddle=2bd6...