Question

I’ve created a function in PostgreSQL that works on a couple of tables and assembles the result based on a parameter passed. It works quite well and from the client’s perspective it looks like a normal table with an additional parameter (i.e. it can be queried like a usual select query).

In order to keep hiding the information about the underlying data, I would also like to create a way to write to the table. I thought I’d create a trigger that executes a function which would basically update the relevant underlying tables. However, I wasn’t able to create a trigger on a function. Is there any way of creating a trigger on anything else but a table? I was also considering of using a view (as I believe on can create a trigger on a view), but then I would need to change the function to become a view which doesn’t suit as I wouldn’t be able to pass in a parameter.

Answer 1

You appear to want to create the equivalent of an updatable view over a function, where you can INSERT, UPDATE or DELETE on a function. This is not possible.

If you’re providing a function-like interface, provide functions for data modification as well.

Alternately, turn your function into a view. Allow them to restrict the view with a WHERE clause instead of passing parameters to a function. Then use a view trigger (PostgreSQL 9.1 and above) or rules (PostgreSQL 9.0 and below, do not use on newer versions if possible) to enable INSERT, UPDATE and DELETE on the view. See CREATE TRIGGER and CREATE RULE. Rules are tricky, so use a view trigger by preference.

PostgreSQL is pretty clever about pushing filters down into views, so SELECT * FROM some_view WHERE some_col = 4 will not generally scan the whole view then filter it. It will “push” the WHERE clause into the view’s query and execute that. So if your view is SELECT * FROM some_table WHERE NOT is_archived PostgreSQL will actually land up executing the equivalent of SELECT * FROM some_table WHERE (NOT is_archived) AND some_col = 4. Because of this you can and often do get a completely different query plan when querying a view for just a few rows vs all rows. There’s an example of this in a post I wrote a while ago.

Just wrapping your function in a view won’t work well unless it’s an SQL function that’s STABLE and not IMMUTABLE (so it can be inlined). You’re best off extracting the SQL from the function and creating the view based on the same SQL, rather than basing it on the function its self.

If your function parameters aren’t used in simple WHERE clauses then it gets more complicated, because there’s no way to pass the parameter into the view like you can in a function. You can create a view over all possible values of the parameter then filter that, but that can lead to truly awful performance if Pg seq-scans the view. In these more complex cases I’d want to offer a function call interface for making modifications.