Всем привет. Отправил вот такое письмо в hackers группу в продолжение

Question

Всем привет. Отправил вот такое письмо в hackers группу в продолжение

темы би темпоральных табличек:
https://www.postgresql.org/message-id/919823407.20191029175436%40yandex.ru
> Thinking some more on this, I now don't think a TODO makes sense, so I
> have removed it.

Please look into this example: https://dbfiddle.uk/?rdbms=postgres_12&fiddle=8e114ccc9f15a30ca3115cdc6c70d247
This is real life code from our production.

You can see that this is important to get correct info about deleted
data

-- EXPECTED app_period: ["2018-08-20", "2018-08-25")
-- ACTUAL app_period: ["2018-08-14", )

> Triggers are designed to check and modify input data, and since DELETE
> has no input data, it makes no sense.

Please put back into TODO list this feature request to allow
triggers to modify output data.

INPUT -- receives data OK (behavior is expected)
UPDATE -- receives and returns data OK (behavior is expected)
DELETE -- returns data FAIL (behavior is not expected)

This is inconsistent to allow modify output data for UPDATE and
restrict to do this for DELETE

Thank you

Yaroslav Как вы думатете, теперь пример достаточно хорош, чтобы можно было принять моё предолжение того, чтобы разрешить менять OLD для операций DELETE?

#backend #devops #pgsql #programming #russian

0

04.12.2019

2 ответов

17 просмотров

doc

нет. почему следующий за тобой тригер должен получать измененные данные?

0

04.12.2019

Yaroslav Schekin · Accepted Answer

А пример-то какой "короткий"! ;) И я ещё не тот начал читать. :( Неужели это нельзя как-то сократить? И да, давать ссылки на внешние сайты (pastes) в -hackers — дурной тон (подумайте о том, что кто-то будет читать это годы спустя, когда этот fiddle, возможно, уже исчезнет).

172 похожих чатов

Всем привет. Отправил вот такое письмо в hackers группу в продолжение

2 ответов

Похожие вопросы