PostgreSQL select now()::timestamp отличается от значения по умолчанию now()::timestamp

В моей программе каждая таблица имеет столбец last_modified:

last_modified int8 DEFAULT (date_part('epoch'::text, now()::timestamp) * (1000)::double precision) NOT NULL

Для обновления я добавил триггер:

CREATE OR REPLACE FUNCTION sync_lastmodified() RETURNS trigger AS $$
BEGIN
  NEW.last_modified := (date_part('epoch'::text, now()::timestamp) * (1000)::double precision);

  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER
  sync_lastmodified
BEFORE UPDATE ON
  ourtable
FOR EACH ROW EXECUTE PROCEDURE
  sync_lastmodified();

Они должны записывать текущее время в виде длинного значения в столбец last_modified при обновлении/вставке. Однако это не работает, как я ожидал.

Чтобы воспроизвести проблему, я сделал обновление и получил следующее:

last_modified value equals 1543576224455 (Friday November 30, 2018 16:10:24 (pm) in time zone Asia/Tashkent (+05))

Почти одновременно запускаю функцию now из pgAdmin:

SELECT now()

и получил результат:

2018-11-30 11:10:36.891426+05

Чтобы проверить системное время в течение нескольких секунд, я запускаю timedatectl status из терминала и получаю следующий результат:

введите здесь описание изображения

Вопрос в том, почему функция now() дает время с разницей в 5 часов, когда я запускаю ее из триггера или как значение по умолчанию при вставке?


person valijon    schedule 30.11.2018    source источник
comment
Из-за проблемы я получаю неправильные результаты при выборе значений в зависимости от времени last_modified.   -  person valijon    schedule 30.11.2018


Ответы (1)


epoch даст вам количество секунд с начала эпохи. Как сказано в в документации:

epoch

Для значений timestamp with time zone количество секунд с 01 января 1970 г. 00:00:00 UTC (может быть отрицательным)

Поскольку вы смещены на 5 часов от UTC, это объясняет разницу.

person Laurenz Albe    schedule 30.11.2018