memory context for tuplesort return values

I've been modifying tuplesort.c to keep all the sort's local data in a
separate memory context, to simplify and speed up cleaning up the data
during tuplesort_end.  I thought this would be a straightforward change,
but was disillusioned when I got a core dump while testing :-(.  On
investigation the problem is that nodeSort.c keeps the tuple pointer
returned by tuplesort.c in a TupleTableSlot, and the order of operations
during plan shutdown is such that the slot tries to pfree the tuple
only after tuplesort_end has been called.  Of course this means it's
pfree'ing already-released memory.

I don't want to give up the idea of keeping sort-local data in a private
context --- it just seems cleaner, as well as faster, than letting it be
mixed into the caller's stuff.  I can see two alternatives:

1. Document an ordering constraint that the result of tuplesort_gettuple
must be pfree'd, if at all, before tuplesort_end.  AFAICT this would
require only one simple change in the existing backend code (add an
ExecClearTuple at a suitable spot in nodeSort.c).  However there is the
potential to break add-on modules, if anyone is using tuplesort directly.

2. Arrange that if the result of tuplesort_gettuple is supposed to be
pfree'd by the caller, it is stored in the caller's context not the
private context.  Unfortunately, this looks like it would be pretty
messy inside tuplesort.c and would force an extra palloc/copy per tuple.
(The hard case is where we are doing the final merge on-the-fly.)

I'm inclined to go with #1 but wanted to see if this would really offend
anyone's sensibilities.
        regards, tom lane