Amit Khandekar <amit.khandekar@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
