Re: delta relations in AFTER triggers
Marti Raudsepp <marti@juffo.org>
From: Marti Raudsepp <marti@juffo.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Heikki Linnakangas <hlinnakangas@vmware.com>,
Kevin Grittner <kgrittn@ymail.com>,
Amit Khandekar <amit.khandekar@enterprisedb.com>,
Robert Haas <robertmhaas@gmail.com>,
David Fetter <david@fetter.org>, Alvaro Herrera <alvherre@2ndquadrant.com>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2014-09-02T14:46:21Z
Lists: pgsql-hackers
On Mon, Sep 1, 2014 at 9:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > OTOH, I agree with Kevin that the things we're talking about are > lightweight relations not variables. My worry is that PL/pgSQL and Postgres's SQL dialect is turning into a Frankenstein monster with many ways to do the same thing, each having different semantics that require effort to reason about. Variables and function arguments are non-contriversial, every experienced coder understands their semantics without thinking twice -- even if they're not familiar with Postgres. The concept of "lightweight relations" that pop into existence when a certain kind of trigger definition is used somewhere in the function stack, without a CREATE TABLE, without being discoverable in information_schema etc., I find needs some more justification than I've seen in this thread. So far I've only heard that it's more convenient to implement in the current PostgreSQL code base. I'm sure more questions would pop up in practice, but as Heikki mentioned: Are such relations also visible to other functions called by the trigger function? * If yes, this introduces non-obvious dependencies between functions. What happens when one trigger with delta relations invokes another trigger, does the previous one get shadowed or overwritten? What are the interactions with search_path? Can an unprivileged function override relation names when calling a SECURITY DEFINER function? * If not, this further inhibits developers from properly modularizing their trigger code (this is already a problem due to the current magic trigger variables). Even if these questions have reasonable answers, it takes mental effort to remember the details. Procedure code debugging, especially triggers, is hard enough due to poor tooling; increasing the cognitive load should not be done lightly. You could argue that CREATE TEMP TABLE already has some of these problems, but it's very rare that people actually need to use that. If delta relations get built on this new mechanism, avoiding won't be an option any more. Regards, Marti
Commits
-
Don't permit transition tables with TRUNCATE triggers.
- 29fd3d9da0ff 10.0 landed
-
Pass EXEC_FLAG_REWIND when initializing a tuplestore scan.
- 304007d9f1f6 10.0 landed
-
Faster expression evaluation and targetlist projection.
- b8d7f053c5c2 10.0 cited
-
Remove obsoleted code relating to targetlist SRF evaluation.
- ea15e18677fc 10.0 cited
-
Implement syntax for transition tables in AFTER triggers.
- 8c48375e5f43 10.0 cited