Re: (Comment)Bug in CteScanNext

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: (Comment)Bug in CteScanNext
Дата
Msg-id 25798.1473181245@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: (Comment)Bug in CteScanNext  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: (Comment)Bug in CteScanNext  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список pgsql-hackers
Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
> On 9/3/16 1:30 PM, Tom Lane wrote:
>> Or we could add something like "But first, we must deal with the special
>> case of reversing direction after reaching EOF."

> I'm working on that, but one thing isn't clear to me... why do we only 
> skip past the last tuple if (!node->leader->eof_cte)? Even if we've hit 
> the end of the underlying node, the tuplestore could still return data, 
> and AFAICT we would still need to move past the last item in the 
> tuplestore, no?

If tuplestore_ateof is true, then what presumably happened in the previous
call is that we fetched a row (moving forward) from the underlying plan,
appended it to the tuplestore, and returned it to the caller.  If the
current call specifies moving backwards, we want to return the tuple
before that one, not the same one again.

Alternatively, if we'd already backed up some and gone forwards again (all
fetching from the tuplestore), then ateof means that the last call
returned the last row currently in the tuplestore.  Again, we don't want
to return that row twice.

On the other hand, if eof_cte is true, then what happened on the last
call is that we tried to fetch forwards, reached EOF on the underlying
query, and returned NULL.  In that case, a backwards fetch *should*
produce the last row in the tuplestore.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Claudio Freire
Дата:
Сообщение: Re: Vacuum: allow usage of more than 1GB of work mem
Следующее
От: Marko Tiikkaja
Дата:
Сообщение: Re: SELECT FOR UPDATE regression in 9.5