On Tue, Apr 20, 2021 at 02:48:35PM +0900, Amit Langote wrote: > Manipulating the contents of es_opened_result_relations directly in > worker.c is admittedly a "hack", which I am reluctant to have other > places participating in. As originally designed, that list is to > speed up ExecCloseResultRelations(), not as a place to access result > relations from. The result relations targeted over the course of > execution of a query (update/delete) or a (possibly multi-tuple in the > future) replication apply operation will not be guaranteed to be added > to the list in any particular order, so assuming where a result > relation of interest can be found in the list is bound to be unstable.
I really hope that this code gets heavily reorganized before considering more features or more manipulations of dependencies within the relations used for any apply operations. From what I can understand, I think that it would be really nicer and less bug prone to have a logic like COPY FROM, where we'd rely on a set of ExecInitResultRelation() with one final ExecCloseResultRelations(), and as bonus it should be possible to not have to do any business with ExecOpenIndices() or ExecCloseIndices() as part of worker.c. Anyway, I also understand that we do with what we have now in this code, so I am fine to live with this patch as of 14. -- Michael
signature.asc
Description: PGP signature
