Re: Let's get rid of SPI_push/SPI_pop

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Let's get rid of SPI_push/SPI_pop
Дата
Msg-id CAFj8pRBXFKsM9z795KTgepLs-7F8+0zMw2-ZUVxh9Zd8=vdf7g@mail.gmail.com
обсуждение исходный текст
Ответ на Let's get rid of SPI_push/SPI_pop  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Let's get rid of SPI_push/SPI_pop
Список pgsql-hackers


2016-11-07 2:16 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:
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 SPI_connect or SPI_finish in an inner function layer.  And
that seems pretty useless, because any such bug in a function would be
immediately detected in simple testing that calls it without any outer
level of SPI calls.

As against that, we have the risk of forgotten SPI_push/SPI_pop calls that
go undetected for years, as just seen in commit fc8b81a29.  We've had that
type of bug before too, cf 0d4899e44.  And then there's the fact that we
put conditional SPI_push/SPI_pop calls into various places, eg deac9488d,
which it seems to me largely destroys whatever debugging value the concept
did have.

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 more complicated.)

We can provide do-nothing macros by these names to avoid an API break
for third-party extensions.

Comments, objections?

cannot be there some performance impacts?

Regards

Pavel
 

                        regards, tom lane


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: pg_hba_file_settings view patch
Следующее
От: "Tsunakawa, Takayuki"
Дата:
Сообщение: Re: [RFC] Should we fix postmaster to avoid slow shutdown?