On 15 August 2014 04:04, Kevin Grittner <kgri...@ymail.com> wrote: > Amit Khandekar <amit.khande...@enterprisedb.com> wrote: > >>>> The execution level itself was almost trivial; it's getting the >>>> tuplestore reference through the parse analysis and planning >>>> phases that is painful for me. >>> I am not sure why you think we would need to refer the >>> tuplestore in the parse analysis and planner phases. It seems >>> that we would need them only in execution phase. Or may be I >>> didn't understand your point. >> Ah I think I understand now. That might be because you are >> thinking of having an infrastructure common to triggers and >> materialized views, right ? > > Well, it's more immediate than that. The identifiers in the > trigger function are not resolved to particular objects until there > is a request to fire the trigger. Ah ok, you are talking about changes specific to the PL language handlers. Yes, I agree that in the plpgsql parser (and in any PL handler), we need to parse such table references in the SQL construct, and transform it into something else. > At that time the parse analysis > needs to find the name defined somewhere. It's not defined in the > catalogs like a table or view, and it's not defined in the query > itself like a CTE or VALUES clause. The names specified in trigger > creation must be recognized as needing to resolve to the new > TuplestoreScan, and it needs to match those to the tuplestores > themselves. One approach that comes to my mind is by transforming such transition table references into a RangeFunction reference while in plpgsql parser/lexer. This RangeFunction would point to a set-returning catalog function that would return rows from the delta tuplestore. So the tuplestore itself would remain a blackbox. Once we have such a function, any language handler can re-use the same interface.
> Row counts, costing, etc. needs to be provided so the > optimizer can pick a good plan in what might be a complex query > with many options. I am also not sure about the costing, but I guess it may be possible to supply some costs to the FunctionScan plan node. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers