Re: [HACKERS] tuplesort_gettuple_common() and *should_free argument
От | Peter Geoghegan |
---|---|
Тема | Re: [HACKERS] tuplesort_gettuple_common() and *should_free argument |
Дата | |
Msg-id | CAH2-Wzn-EFddFairDVtJSopb4N5YwKO69E8F=iOW5V9for3srg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] tuplesort_gettuple_common() and *should_free argument (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: [HACKERS] tuplesort_gettuple_common() and *should_free argument
Re: tuplesort_gettuple_common() and *should_free argument Re: tuplesort_gettuple_common() and *should_free argument |
Список | pgsql-hackers |
On Wed, Jan 25, 2017 at 3:11 PM, Peter Geoghegan <pg@heroku.com> wrote: > On Wed, Jan 25, 2017 at 3:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Please. You might want to hit the existing ones with a separate patch, >> but it doesn't much matter; I'd be just as happy with a patch that did >> both things. > > Got it. Attached is a patch that does both things at once. The internal function tuplesort_gettuple_common() still mentions repeated fetches, since that context matters to its internal callers. The various external-facing functions have a simpler, stricter contract, as discussed. I didn't end up adding a line like "copy=FALSE is recommended only when the next tuplesort manipulation will be another tuplesort_gettupleslot fetch into the same slot", which you suggested. When the tuplesort state machine is in any state following "performing" a sort, there are very few remaining sane manipulations. Just things like skipping or seeking around for tuples, and actually ending the tuplesort and releasing resources. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
В списке pgsql-hackers по дате отправления: