• Heikki Linnakangas's avatar
    Create ResultRelInfos later in InitPlan, index them by RT index. · 1375422c
    Heikki Linnakangas authored
    Instead of allocating all the ResultRelInfos upfront in one big array,
    allocate them in ExecInitModifyTable(). es_result_relations is now an
    array of ResultRelInfo pointers, rather than an array of structs, and it
    is indexed by the RT index.
    
    This simplifies things: we get rid of the separate concept of a "result
    rel index", and don't need to set it in setrefs.c anymore. This also
    allows follow-up optimizations (not included in this commit yet) to skip
    initializing ResultRelInfos for target relations that were not needed at
    runtime, and removal of the es_result_relation_info pointer.
    
    The EState arrays of regular result rels and root result rels are merged
    into one array. Similarly, the resultRelations and rootResultRelations
    lists in PlannedStmt are merged into one. It's not actually clear to me
    why they were kept separate in the first place, but now that the
    es_result_relations array is indexed by RT index, it certainly seems
    pointless.
    
    The PlannedStmt->resultRelations list is now only needed for
    ExecRelationIsTargetRelation(). One visible effect of this change is that
    ExecRelationIsTargetRelation() will now return 'true' also for the
    partition root, if a partitioned table is updated. That seems like a good
    thing, although the function isn't used in core code, and I don't see any
    reason for an FDW to call it on a partition root.
    
    Author: Amit Langote
    Discussion: https://www.postgresql.org/message-id/CA%2BHiwqGEmiib8FLiHMhKB%2BCH5dRgHSLc5N5wnvc4kym%2BZYpQEQ%40mail.gmail.com
    1375422c
trigger.c 177 KB