Akina

pgadmin не дает исправить.

Значит, используйте SQL-запрос. И повнимательнее - чтобы количество ошибок при выполнении запроса не увеличилось...

таблица не имеет primary key

Создайте в таблице первичный ключ. Лучше синтетический.
С другой стороны, вы пишете:

отредактировать строки, связанные с этим пользователем

Если есть связанные записи - значит, есть внешние ключи и соответственно как минимум уникальные индексы. Что-то как-то не бьётся...

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

Создайте соответствующие ограничения (UNIQUE index) в структуре.

Мне бы не хотелось менять структуру таблицы

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

может есть вариант функции "EXTRACT" способный обрабатывать значение Null

Вотще! Это забота программиста - обеспечить корректное значения параметра.

SELECT EXTRACT(epoch FROM COALESCE( MAX(t.date_x), {default datetime literal} )) 
FROM T

Если очень надо- можно ещё сверху NULLIF() наслоить.

Альтернативное решение - явное приведение типа:

SELECT EXTRACT(epoch FROM CAST( MAX(t.date_x) AS TIMESTAMP)) 
FROM T

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?

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

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