On Mon, Nov 14, 2005 at 10:14:53AM -0500, Tom Lane wrote:
> The minimum-change way to fix the bug would be to revert the logic
> change in nodeUnique.c and go back to maintaining a separate tuple copy.
> But I'm thinking that this sort of thing could happen again. ISTM
> it's not intuitive to allow a plan node's caller to scribble on the plan
> node's result slot. An alternative solution would be to require
> execMain.c to keep an extra tuple table slot that has no other purpose
> than to temporarily hold replacement tuples during ExecInsert and
> ExecUpdate.
I agree that execMain should play with its own memory. The rule that a
node's result slot is valid until the next call is good because it
solves the memory management issue. By allowing other people to
scribble over your slot may cause issues w.r.t. knowing when you can
safely free it.
From a modularity point of view, nodes own their tupleslots and should
be able to rely on them not changing...
Hope this helps,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.
