Re: *_to_xml() should copy SPI_processed/SPI_tuptable

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: *_to_xml() should copy SPI_processed/SPI_tuptable
Дата
Msg-id 23555.1536188083@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: *_to_xml() should copy SPI_processed/SPI_tuptable  (Chapman Flack <chap@anastigmatix.net>)
Ответы Re: *_to_xml() should copy SPI_processed/SPI_tuptable  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Chapman Flack <chap@anastigmatix.net> writes:
> On 09/05/18 18:07, Tom Lane wrote:
>> * Replace SPI_tuptable et al with macros that access fields in the
>> current SPI stack level (similar to the way that, eg, errno works
>> on most modern platforms).  This seems do-able, if a bit grotty.

> It would mean they'd have to *be* in the stack frame, where they
> currently aren't;

Right, I was assuming that was obvious ...

> Another alternative might be to have SPI_connect save them and
> SPI_finish put them back, which leaves you just responsible for
> reasoning about your own code. You'd still be expected to save them
> across your own uses of other SPI calls, but no longer exposed to
> spooky action at a distance from nested uses of SPI in stuff you call.

Hmm.  I'd thought about that briefly and concluded that it didn't offer
a full fix, but on reflection it's not clear why it'd be any less of
a fix than the macroized-SPI_tuptable approach.  You end up with
per-SPI-stack-level storage either way, and while that isn't perfect
it does go a long way, as you say.  More, this has the huge advantage
of being back-patchable, because there'd be no API/ABI change.

            regards, tom lane


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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: On the need for a snapshot in exec_bind_message()
Следующее
От: Tom Lane
Дата:
Сообщение: Re: On the need for a snapshot in exec_bind_message()