Re: *_to_xml() should copy SPI_processed/SPI_tuptable

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: *_to_xml() should copy SPI_processed/SPI_tuptable
Дата
Msg-id e0d587a5-6b41-a768-0f42-e17a2e984b82@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: *_to_xml() should copy SPI_processed/SPI_tuptable  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: *_to_xml() should copy SPI_processed/SPI_tuptable  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 06/09/2018 18:25, Tom Lane wrote:
> Here's a proposed patch along that line.  I included SPI_result (SPI's
> equivalent of errno) in the set of saved-and-restored variables,
> so that all the exposed SPI globals behave the same.
> 
> 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.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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

Предыдущее
От: Fabrízio de Royes Mello
Дата:
Сообщение: Re: Prevent concurrent DROP SCHEMA when certain objects are beinginitially created in the namespace
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: [HACKERS] Restricting maximum keep segments by repslots