Re: delta relations in AFTER triggers

On Thu, Jan 22, 2015 at 02:41:42PM +0000, Kevin Grittner wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> > Another idea is to change what actually gets passed to the parser
> > callback. Right now we just pass the PLpgSQL_expr. If we created a
> > new structure that contained that plus the PLpgSQL_execstate, we'd be
> > in fine shape. But this sort of gets at the root of the problem here:
> > with variables, the parser callback doesn't return the actual *value*,
> > it returns a Param node that will later, at execution time, be looked
> > up to find the actual value. With relations, we're sort of doing the
> > same thing - the tuplestore RTE doesn't need to contain the actual
> > data, just the tuple descriptor. But the data structures from which
> > we can get that information also contain the actual execution-time
> > information, so passing them into parse-time callbacks seems like it
> > might be, if nothing else, a recipe for future bugs.
>
> That was, of course, why this patch evolved to using this structure
> during parsing:
>
> typedef struct TsrmdData
> {
> char *name; /* name used to identify the tuplestore */
> TupleDesc tupdesc; /* description of result rows */
> } TsrmdData;
>
> typedef TsrmdData *Tsrmd;
>
> ... and this during execution:
>
> typedef struct TsrData
> {
> TsrmdData md;
> Tuplestorestate *tstate; /* data (or tids) */
> } TsrData;
>
> typedef TsrData *Tsr;
>
> The big problem, as I see it, is how to deliver these to where they
> are needed. I didn't think it was that hard to do with the parser
> hook; it's what to do to get the execution time structure to where
> it's needed that I can't figure out. Passing it with the
> parameters is tricky because we're often passing a NULL for the
> reference to the parameter list when we need these. Trying to coax
> the executor to pass in a parameter list when there are no
> parameters, just these ephemeral relations, seems very tricky and
> all solutions I have tried (other than the one Heikki and others
> have objected to) very fragile.
>
> In short, the only solution which I've been able to come up with
> that works (and seems to me solid enough to commit) is the one that
> Hekki, Tom, and Robert seem to think should be made more like
> parameter handling; and every attempt at handling these relations
> like parameters seems to me too fragile for me to feel it is worthy
> of commit.
>
> We're really down to the wire on getting this feature into 9.5; and
> we're way past what was initially my goal, which was to build on
> this to get some incremental maintenance of (some types of simple)
> materialized views into 9.5. IMO we need to be able to build up
> tuplestores and easily reference them from within complex queries
> to create any sane and efficient implementation of incremental
> maintenance of materialized views. This patch was mainly intended
> to make progress on the MV front, with an incidental benefit of
> providing a standard feature that I have seen requested a few times.

[almost 17 months later]

It seems like now is getting close to the time to get this into
master. The patch might have suffered from some bit rot, but the
design so far seems sound.

What say?

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate