On Tue, Jan 10, 2017 at 6:06 AM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/01/05 5:50, Robert Haas wrote: >> On Tue, Dec 27, 2016 at 3:59 AM, Amit Langote >> <langote_amit...@lab.ntt.co.jp> wrote: >>> Patches 0001 to 0006 unchanged. >> >> Committed 0001 earlier, as mentioned in a separate email. Committed >> 0002 and part of 0003. > > Thanks! I realized however that the approach I used in 0002 of passing > the original slot to ExecConstraints() fails in certain situations. For > example, if a BR trigger changes the tuple, the original slot would not > receive those changes, so it will be wrong to use such a tuple anymore. > In attached 0001, I switched back to the approach of converting the > partition-tupdesc-based tuple back to the root partitioned table's format. > The converted tuple contains the changes by BR triggers, if any. Sorry > about some unnecessary work.
Hmm. Even with this patch, I wonder if this is really correct. I mean, isn't the root of the problem here that ExecConstraints() is expecting that resultRelInfo matches slot, and it doesn't? And why isn't that also a problem for the things that get passed resultRelInfo and slot after tuple routing and before ExecConstraints? In particular, in copy.c, ExecBRInsertTriggers. Committed 0002. -- Robert Haas EnterpriseDB: 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
