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. 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. 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'm finding the planner work here to be harder than everything else put together. On the bright side, once I'm done, I might know enough about the planner to do things a lot faster next time. :-) -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers