Re: delta relations in AFTER triggers

On 08/27/2014 02:26 AM, Kevin Grittner wrote:
> spi-tuplestore-registry allows tuplestores, with associated name
> and TupleDesc, to be registered with the current SPI connection.
> Queries planned or executed on that connection will recognize the
> name as a tuplestore relation.  It doesn't care who is registering
> the tuplestores or what happens to them.  It doesn't depend on
> anything else.
> 5 files changed, 445 insertions(+)
>
> ...
>
> plpgsql-after-trigger-transition-tables takes the tuplestores from
> TriggerData and registers them with SPI before trigger planning and
> execution.  It depends on the trigger-transition-tables and
> spi-tuplestore-registry patches to build, and won't do anything
> useful at run time without the executor-tuplestore-relations patch.
> 3 files changed, 37 insertions(+), 11 deletions(-)

This is a surprising way to expose the NEW/OLD relations to the 
planner/executor. The problem is the same as with making PL/pgSQL 
variables available to the planner/executor in queries within a PL/pgSQL 
function, and the solution we have for that is the "parser hooks" you 
pass to SPI_prepare_params. This tuplestore registry is a different 
solution to the same problem - we could've implemented parameters with a 
registry like this as well. Let's not mix two different designs.

I suggest adding a new hook to the ParseState struct, (p_rangevar_hook 
?). The planner calls it whenever it sees a reference to a table, and 
the hook function returns back some sort of placeholder reference to the 
tuplestore. With variables, the hook returns a Param node, and at 
execution time, the executor calls the paramFetch hook to fetch the 
value of the param. For relations/tuplestores, I guess we'll need to 
invent something like a Param node, but for holding information about 
the relation. Like your TsrData struct, but without the pointer to the 
tuplestore. At execution time, in the SPI_execute call, you pass the 
pointer to the tuplestore in the ParamListInfo struct, like you pass 
parameter values.

Does this make sense? In essence, make the relations work like PL/pgSQL 
variables do. If you squint a little, the new/old relation is a variable 
from the function's point of view, and a parameter from the 
planner/executor's point of view. It's just a variable/parameter that 
holds a set of tuples, instead of a single Datum.

- Heikki