Re: *_to_xml() should copy SPI_processed/SPI_tuptable

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Chapman Flack <chap(at)anastigmatix(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: *_to_xml() should copy SPI_processed/SPI_tuptable
Date: 2018-09-06 20:40:00
Message-ID: 18151.1536266400@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Gierth 2018-09-06 20:47:40 Re: *_to_xml() should copy SPI_processed/SPI_tuptable
Previous Message Tomas Vondra 2018-09-06 20:34:33 Re: [PATCH] Incremental sort (was: PoC: Partial sort)