| 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: | Whole Thread | Raw Message | 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
| 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() |