ВСТАВИТЬ ...ВОЗВРАЩАЮЩИЙСЯ ..появляется пустой, когда BEFORE trigger отменяет оператор

Question

У меня есть триггер PostgreSQL before insert при создании, который в основном перенаправляет вставки во вложенные таблицы.Как только я вставляю запись, я хочу прервать запрос, чтобы избежать дублирования данных (не вставляя в родительскую таблицу), поэтому я использую return NULL в триггере.Проблема в том, что мне нужно, чтобы запись была возвращена, чтобы я мог получить идентификатор.Если я возвращаю NULL, я получаю NULL.

Вышеуказанная проблема обсуждается по ссылке ниже:Триггер PostgreSQL ничего не возвращает

В одном из ответов говорится вставить в родительскую таблицу (не возвращая null, а возвращая new) и использовать триггер AFTER insert для удаления его из родительской таблицы.Но я смотрю на 1000 операций записи в секунду, и это может быть серьезной проблемой для производительности из-за deletes.is есть какой-нибудь другой способ сделать это?

Чтобы быть точным, есть ли способ вернуть идентификатор вставленной строки, не вставляя ее в родительскую таблицу и не удаляя ее позже.

Answer 1

Я написал ответ, на который вы ссылаетесь.Как я уже намекал там:

Вы также могли бы использовать RULE ... INSTEAD .. для этой цели.

RULE

Правила это может быть сложно.Я бы предпочел использовать триггеры там, где это возможно. Обязательно немного почитайте, прежде чем вы попробуете это:

CREATE OR REPLACE RULE tbl_ins AS
ON INSERT TO tbl
DO INSTEAD
INSERT INTO tbl2 (col1, col2, ...)  -- just do mention columns where ...
VALUES (NEW.col1, NEW.col2, ...)    -- ... you want to insert column defaults
RETURNING tbl2.*

Это вернуло бы значения из tbl2 избегая при этом фантомных строк. Однако, согласно документации по CREATE RULE:

В правиле для INSERT, UPDATE, или DELETE в представлении вы можете добавить RETURNING предложение, которое генерирует столбцы представления.Это предложение будет использоваться для вычисления выходных данных, если правило запускается с помощью INSERT RETURNING, UPDATE RETURNING, или DELETE RETURNING команда соответственно.Когда правило запускается командой без RETURNING, это правило RETURNING предложение будет проигнорировано. Текущая реализация допускает только безусловное INSTEAD правила, которые должны содержать RETURNING;

Жирный акцент - мой.
Раз уж вы упомянули sub-tables, Я так понимаю , вам понадобятся условия для распределения вставок...

currval() / lastval()

Если вы работаете с триггером FOR EACH ROW вы можете легко извлекать соответствующие значения из последовательностей с помощью currval() / lastval().Самое сложное - вернуть эти значения из триггерной функции.Я могу думать только о записи во временную таблицу.Нужно немного подумать , когда что - то создавать , а когда отказаться от этого ...

Я бы , наверное, так и сделал переосмыслите весь подход и перенаправлять данные на несколько INSERT инструкции к фактическим целевым таблицам ...