On Wed, Jun 21, 2017 at 5:28 AM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote:>> The comment "UPDATE/DELETE cases are handled above" is referring to >> the code that initializes the WCOs generated by the planner. You've >> modified the comment in your patch, but the associated code: your >> updated comment says that only "DELETEs and local UPDATES are handled >> above", but in reality, *all* updates are still handled above. And >> then they are handled again here. Similarly for returning lists. >> It's certainly not OK for the comment to be inaccurate, but I think >> it's also bad to redo the work which the planner has already done, >> even if it makes the patch smaller. > > I guess this has to do with the UPDATE turning into DELETE+INSERT. So, it > seems like WCOs are being initialized for the leaf partitions > (ResultRelInfos in the mt_partitions array) that are in turn are > initialized for the aforementioned INSERT. That's why the term "...local > UPDATEs" in the new comment text. > > If that's true, I wonder if it makes sense to apply what would be > WCO_RLS_UPDATE_CHECK to a leaf partition that the tuple will be moved into > by calling ExecInsert()?
I think we probably should apply the insert policy, just as we're executing the insert trigger. >> Also, I feel like it's probably not correct to use the first result >> relation as the nominal relation for building WCOs and returning lists >> anyway. I mean, if the first result relation has a different column >> order than the parent relation, isn't this just broken? If it works >> for some reason, the comments don't explain what that reason is. > > Yep, it's more appropriate to use > ModifyTableState->rootResultRelationInfo->ri_RelationDesc somehow. That > is, if answer to the question I raised above is positive. The questions appear to me to be independent. -- 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