Re: *_to_xml() should copy SPI_processed/SPI_tuptable

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Chapman Flack <chap(at)anastigmatix(dot)net>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: *_to_xml() should copy SPI_processed/SPI_tuptable
Date: 2018-09-05 22:54:43
Message-ID: 23555.1536188083@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Chapman Flack <chap(at)anastigmatix(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-09-05 23:11:56 Re: On the need for a snapshot in exec_bind_message()
Previous Message Andres Freund 2018-09-05 22:54:38 Re: On the need for a snapshot in exec_bind_message()