Re: *_to_xml() should copy SPI_processed/SPI_tuptable

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: *_to_xml() should copy SPI_processed/SPI_tuptable
Дата
Msg-id 18151.1536266400@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: *_to_xml() should copy SPI_processed/SPI_tuptable  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список pgsql-hackers
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 06/09/2018 18:25, Tom Lane wrote:
>> Also, in further service of providing insulation between SPI nesting
>> levels, I thought it'd be a good idea for SPI_connect() to reset the
>> globals to zero/NULL after saving them.  This ensures that a nesting
>> level can't accidentally be affected by the state of an outer level.
>> It's barely possible that there's somebody out there who's *intentionally*
>> accessing state from a calling SPI level, but that seems like it'd be
>> pretty dangerous programming practice.  Still, maybe there's an argument
>> for omitting that hunk in released branches.

> These look like good changes.  I'm not sure about backpatching them, but
> as you say the chances that someone wants to do this intentionally are low.

Yeah.  I'd put a higher probability on the idea that this will fix
somebody's latent bug in code that's never been tested inside an
outer level of SPI call.  It would, for example, work to rely on
SPI_tuptable being initially NULL, as long as you hadn't tried it
inside an outer call.

            regards, tom lane


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

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: [PATCH] Incremental sort (was: PoC: Partial sort)
Следующее
От: Andrew Gierth
Дата:
Сообщение: Re: *_to_xml() should copy SPI_processed/SPI_tuptable