Akina

PostgreSQL: Identifiers and Key Words
MySQL: Identifier Case Sensitivity
Прочитать и изучить ОЧЕНЬ внимательно - от этих ссылок и всё вокруг. Особое внимание - различиям между квотированными и неквотированными идентификаторами.

Данные импортируются с названием колонок заглавными буквами.

Ну, значит, так импортируешь. По-любому, это твой косяк.

NOTIFY
LISTEN
Хотя как по мне, один запрос в 10 минут - это ни о чём.

мне необходимо удалить строку из одной таблицы и эту же строку добавить в другую таблицу.

В PostgreSQL это вообще элементарная операция. Можно удалить запись в CTE и вставить её во внешнем запросе, можно наоборот. То, как выполнять, определяется возможными зависимостями и интерференциями.

WITH cte AS (
    DELETE
    FROM table1
    WHERE {criteria}
    RETURNING *
)
INSERT 
INTO table2
SELECT *
FROM cte;

-- или 

WITH cte AS (
    INSERT 
    INTO table2
    SELECT *
    FROM table1
    WHERE {criteria}
    RETURNING id
)
DELETE
FROM table1
WHERE id IN (
    SELECT id
    FROM cte
);

Sample fiddle

Само собой, вместо звёзд может быть (даже правильнее сказать - должен быть) перечень определённых полей и выражений.

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

WITH cte AS (
  SELECT *,
         SUM((flag IS NULL) :: INT) OVER (PARTITION BY user_id ORDER BY product_id ASC) grp
  FROM test
  )
SELECT product_id, user_id, flag,
       DENSE_RANK() OVER (PARTITION BY user_id ORDER BY grp ASC) "rank"
FROM cte
ORDER BY 1,2;

fiddle

Запрос

SELECT * FROM base WHERE domain LIKE '%habr%' LIMIT 10000;

Какой это нахрен поиск "по совпадениям"??? Это, блин, поиск по подстроке!!! причём в любом месте строки.

С таким шаблоном поиска можете с обычными индексами вообще не трахаться, по причине абсолютной бессмысленности действа. Читайте про GIN, GiST, RUM и прочие виды индексов и поиск с их использованием.

Будет что-то вроде

SELECT *,
       ( SELECT value
         FROM tablename t2
         WHERE t1.year - 1 = t2.year
         ORDER BY created_at DESC LIMIT 1 
         ) AS prev_value
FROM tablename t1;

Схематично:

WITH cte AS (
    SELECT *, ROW_NUMBER() OVER (ORDER BY id) rn
    FROM tablename
    WHERE type = @type
    )
SELECT /* DISTINCT */ t2.*
FROM cte t1
JOIN cte t2 ON t2.rn IN (t1.rn - 1, t1.rn, t1.rn + 1)
WHERE t1.status = @status
ORDER BY t2.rn

Задача заключается в том, чтобы добавить еще одну колонку для мультиязычности, назвав DocTypeEn, в котором будет перевод.

Ага... а потом захочется на немецкий, на китайский... так и будешь поля добавлять?

Классический подход - таблица текстовых литералов

CREATE TABLE translation (
    token_id INT,      -- идентификатор строки
    language_id INT,   -- идентификатор языка
    PRIMARY KEY (token_id, language_id),
    value VARCHAR(100) NULL DEFAULT NULL
    );

Соответственно зная номер строки, который нужен, и язык, получаем значение

SELECT value
FROM translation
JOIN language USING (language_id)
WHERE token_id = @token_id
  AND language_name = @language_name;

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

SELECT COALESCE((
    SELECT value
    FROM translation
    JOIN language USING (language_id)
    WHERE token_id = @token_id
      AND language_name = @language_name;
    ), (
    SELECT value
    FROM translation
    JOIN language USING (language_id)
    WHERE token_id = @token_id
      AND language_name = @default_language_name;
    )) value;

То есть для литералов. имеющих перевод, возвращаются именно они, а для ещё не имеющих - значение на языке по умолчанию.

============

С другой стороны, вывод сообщений на экран - это интерактивное взаимодействие, где начхать на производительность. А коли так, то сообщения можно хранить в одном поле в виде JSON объекта, типа

{
    "ru":"Выход",
    "en":"Quit"
}

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

Как реализовать надежную запись списка данных без пропусков значения автоинкремента id?

Никак НЕ РЕАЛИЗОВЫВАТЬ.

Оставь автоинкремент в покое - он обязан обеспечивать только уникальность, и не более. Нужна непрерывная нумерация? Создай для неё ОТДЕЛЬНОЕ поле, и нумеруй программно. Триггеры в помощь.

Оператор ?| в PostgreSQL выполняет поиск строковых значений в списке элементов массива или ключей (имён атрибутов) объекта:

jsonb ?| text[] → boolean

Do any of the strings in the text array exist as top-level keys or array elements?

'{"a":1, "b":2, "c":3}'::jsonb ?| array['b', 'd'] → t

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

В PostgreSQL нет встроенных функции или оператора для указанной задачи или для проверки на пересечение двух числовых JSON массивов. Возможное решение - разобрать JSON-массив на элементы, собрать в обычный массив и использовать для двух массивов оператор &&

Если принять такую формулировку:

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

то запрос на получение "первичных" товаров будет такой:

WITH cte AS (
    SELECT t1.cat_id, RANK() OVER (ORDER BY COUNT(t2.cat_id) DESC) rnk
    FROM user_to_cat t1
    JOIN user_to_cat t2 ON t1.user_id = t2.user_id
                       AND t1.cat_id <> t2.cat_id
    GROUP BY 1
    )
SELECT category.code
FROM cte
JOIN category ON category.id = cte.cat_id
WHERE rnk = 1

На данных из fiddle запрос даст 2 товара - orange и pear, оба они участвуют в 6 парах, тогда как apple участвуют в 4, а lemon в 2 парах.