Gregory Stark <stark@enterprisedb.com> writes:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>> [ greps a bit... ] It looks like the only way that you could expose the
>> bug in the current state of the system would be if the sort/limit with
>> the outer parameter were the inside of a nestloop join in the subplan.
> I finally managed to trigger this case and found that the checks don't
> actually work:
Oh dear.
> Attached is a small patch which fixes this case.
This patch makes what was already a hack into a full-fledged crock (and
it's not just the self-doubting comments that make me distrust it).
I think we need to rip out this ad-hoc parameter change signaling code
and make it work through the regular chgParam mechanism. Not sure about
details though. There may be no clean solution short of folding
Sort and Limit into a single node type.
> I think it would be worthwhile adding a method to tuplesort to ask whether
> random access is possible and how many tuples were actually kept. Then
> nodeSort could ask it those values instead of just remembering what values
> were requested.
I disagree with this line of development, as it amounts to exposing
tuplesort implementation details as API.
regards, tom lane