Re: [HACKERS] Let's get rid of SPI_push/SPI_pop

2016-11-07 Thread Tom Lane
I wrote: > Pavel Stehule writes: >> 2016-11-07 2:16 GMT+01:00 Tom Lane : >>> So I think we should just delete these functions and adjust SPI_connect >>> and SPI_finish so that they just push/pop a context level unconditionally. >>> (Which will make

Re: [HACKERS] Let's get rid of SPI_push/SPI_pop

2016-11-07 Thread Pavel Stehule
2016-11-07 15:47 GMT+01:00 Tom Lane : > Pavel Stehule writes: > > 2016-11-07 2:16 GMT+01:00 Tom Lane : > >> So I think we should just delete these functions and adjust SPI_connect > >> and SPI_finish so that they just push/pop a

Re: [HACKERS] Let's get rid of SPI_push/SPI_pop

2016-11-07 Thread Tom Lane
Pavel Stehule writes: > 2016-11-07 2:16 GMT+01:00 Tom Lane : >> So I think we should just delete these functions and adjust SPI_connect >> and SPI_finish so that they just push/pop a context level unconditionally. >> (Which will make them simpler, not

Re: [HACKERS] Let's get rid of SPI_push/SPI_pop

2016-11-06 Thread Pavel Stehule
2016-11-07 2:16 GMT+01:00 Tom Lane : > The intent of SPI_push/SPI_pop seems to be to draw a boundary line between > nested layers of SPI callers. Which is fine, but the SPI_connect and > SPI_finish calls of the inner layer would suffice for that. AFAICS, > the only thing

[HACKERS] Let's get rid of SPI_push/SPI_pop

2016-11-06 Thread Tom Lane
The intent of SPI_push/SPI_pop seems to be to draw a boundary line between nested layers of SPI callers. Which is fine, but the SPI_connect and SPI_finish calls of the inner layer would suffice for that. AFAICS, the only thing that SPI_push/SPI_pop buy for us is the ability to detect a missing