Re: SPI_getvalue calls output function w/o pushing existing SPI connection + 2 extra issues - Mailing list pgsql-bugs

From Tom Lane
Subject Re: SPI_getvalue calls output function w/o pushing existing SPI connection + 2 extra issues
Date
Msg-id 4312.1165942102@sss.pgh.pa.us
Whole thread Raw
In response to Re: SPI_getvalue calls output function w/o pushing existing SPI connection + 2 extra issues  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-bugs
Alvaro Herrera <alvherre@commandprompt.com> writes:
> The question that jumps at me is why are you using SPI inside a type's
> output function?  You should really avoid doing that.

Offhand it seems like it should work, but the real problem is that there
are probably a ton of code paths besides SPI_getvalue() that would need
to be changed to make it bulletproof.  I don't have a big problem with
adding SPI_push/pop inside SPI_getvalue, but what else might need to
change?

> If you absolutely need to do it, enclosing the function in SPI_push/pop
> seems to me the least bad answer.

That would be the Wrong Thing if the function could ever be called when
*not* connected to SPI, which of course is the normal case for a type
I/O function.  Correct code would be something like

    bool connected = false;

    if (_SPI_curid + 1 == _SPI_connected)        /* connected */
    {
        connected = true;
        SPI_push();
    }

    ... do it ...

    if (connected)
        SPI_pop();

and this is only possible inside spi.c because those variables aren't
exported.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: 8.2 pl/pgsql crash bug (WAS: [pgadmin-support] Error craches
Next
From: Tom Lane
Date:
Subject: Re: User-defined type name begins with the underscore character (_) can be created