Instead of triggers in PostgreSQL, how can I stop repeating column names? - sql

Question

I am trying to create a simple table inheritance hierarchy from my entity relationship model in PostgreSQL.
For this, I have created the following tables:
CREATE TABLE base (
id integer PRIMARY KEY,
title varchar(40),
test integer
);
CREATE TABLE sub (
id integer REFERENCES base(id) PRIMARY KEY,
count integer
);
Now, since how the inheritance is solved on the DB does not need to concern the application, I also created a view that the application will access. All operations from the application should be performed on the view, and as such, I also need an instead of trigger to perform updates, inserts and deletes. The view definition and the trigger looks like this:
CREATE VIEW sub_view AS
SELECT s.count, b.title, b.test, b.id FROM sub s
JOIN base b ON b.id = s.id;
--TRIGGER
CREATE OR REPLACE FUNCTION instead_of_f()
RETURNS trigger AS
$$
BEGIN
IF TG_OP = 'INSERT' THEN
INSERT INTO base(id, title, test) VALUES (NEW.id, NEW.title, NEW.test);
INSERT INTO sub(id, test) VALUES (NEW.id, NEW.test);
RETURN NEW;
ELSIF TG_OP = 'UPDATE' THEN
UPDATE base SET title = NEW.title, test = NEW.test WHERE id = OLD.id;
UPDATE sub SET count = NEW.count WHERE id = OLD.id;
RETURN NEW;
ELSIF TG_OP = 'DELETE' THEN
DELETE FROM sub WHERE id = OLD.id;
DELETE FROM base WHERE id = OLD.id;
RETURN NULL;
END IF;
END;
$$ LANGUAGE PLPGSQL;
CREATE TRIGGER instead_of_dml_trig
INSTEAD OF INSERT OR UPDATE OR DELETE ON
sub_view FOR EACH ROW
EXECUTE PROCEDURE instead_of_f();
This basically works fine, but it is tedious and not very maintainable to have to repeat all the column names over and over again. Ideally, I would like to write something like this for the view instead:
CREATE VIEW sub_view AS
SELECT * FROM sub s JOIN base b ON b.id = s.id;
And instead of the insert statements in the trigger:
INSERT INTO base VALUES NEW.*;
INSERT INTO sub VALUES NEW.*;
Is this somehow possible? I couldn't find anything similar, except for audit triggers, and those just saved the NEW and OLD records as a string. In this contrived example it would be easy enough to add new columns or delete them as the base/sub tables change, but as soon as there are a few more sub tables and more columns this becomes practically unmaintainable.

Answer 1

Like Craig suggested, I ended up solving it in my application directly, not on the database. My application knows all the relevant columns from the views, as well as the base types, so it ended up being easier to just create the trigger and the view in the migrations there.