回复：A problem in ExecModifyTable

Поиск
Список
Период
Сортировка
От 李杰(慎追)
Тема 回复：A problem in ExecModifyTable
Дата
Msg-id a42b7cb5-e124-4387-a290-cdfbaf828d37.adger.lj@alibaba-inc.com
обсуждение исходный текст
Ответ на Re: A problem in ExecModifyTable  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: A problem in ExecModifyTable
Список pgsql-hackers
Дерево обсуждения
  
Hi, David

    Your answer explains that we still need to ModifyTable node without Leaf partitions.
    You are right about this.
        
     But you can review the source code again,    
      ```
        /*
        * Fetch rows from subplan, and execute the required table modification
        * for each row.
        */
        for (;;)
        {
            ...
            /* No more tuples to process? */
            if (TupIsNull(planSlot))
                break;

            ....
            /*
             * For UPDATE/DELETE, fetch the row identity info for the tuple to be
             * updated/deleted.  For a heap relation, that's a TID; otherwise we
             * may have a wholerow junk attr that carries the old tuple in toto.
             * Keep this in step with the part of ExecInitModifyTable that sets up
             * ri_RowIdAttNo.
             */
            if (operation == CMD_UPDATE || operation == CMD_DELETE)
            {
                char        relkind;
                Datum       datum;
                bool        isNull;
                relkind = resultRelInfo->ri_RelationDesc->rd_rel->relkind;
                if (relkind == RELKIND_RELATION ||
                    relkind == RELKIND_MATVIEW ||
                relkind == RELKIND_PARTITIONED_TABLE)

        ...
        }

        ```
        We can see that if the scanned tuple is NULL, it will break.
        Therefore, this step will never be achieved that is to extract ctid.

        >We'll need some sort of ResultRelInfo in the case that all partitions
        >are pruned.  

          In this case, the tuple returned should be null. 

        >Using the one for the partitioned table is convenient.  I
        >believe that's required if there are any statement-level triggers on
        >the partitioned table or if there's a RETURNING clause.
         
        If the tuple to be modified is null, you do not need to process RETURNING clause.
        statement-level triggers cannot use tuple, and triggers on partitioned tables cannot have transition tables.
        I set Assert(relkind! = RELKIND_PARTITIONED_TABLE);  in the code, But it never arrives.

        Did I not understand your expression clearly?
        Could you provide me with a case to verify it? 

        Thank you very much for your answer.
    
        Regards & Thanks Adger
        
        
            

В списке pgsql-hackers по дате отправления: