Remaining calls of heap_close/heap_open in the tree
Hi all,
I have just bumped into $subject, and we now use the table_*
equivalents in the code. Any objections to the simple patch attached
to clean up that?
Thanks,
--
Michael
Attachments:
heap-close-open.patchtext/x-diff; charset=us-asciiDownload+4-4
Hi,
On 2019-10-17 10:47:06 +0900, Michael Paquier wrote:
I have just bumped into $subject, and we now use the table_*
equivalents in the code. Any objections to the simple patch attached
to clean up that?
They're not really "remaining", as much as having been introduced after
the introduction of table_open()/close()...
Wonder if it's worth removing the backward compat ones from master? I
don't quite think so, but...
Greetings,
Andres Freund
Andres Freund <andres@anarazel.de> writes:
On 2019-10-17 10:47:06 +0900, Michael Paquier wrote:
I have just bumped into $subject, and we now use the table_*
equivalents in the code. Any objections to the simple patch attached
to clean up that?
They're not really "remaining", as much as having been introduced after
the introduction of table_open()/close()...
Wonder if it's worth removing the backward compat ones from master? I
don't quite think so, but...
If we don't remove 'em, we'll keep getting new calls from patches that
haven't been updated.
regards, tom lane
On Thu, Oct 17, 2019 at 01:04:50AM -0700, Andres Freund wrote:
Wonder if it's worth removing the backward compat ones from master? I
don't quite think so, but...
I would vote for the removal so as we'll never see that again in
core. Let's see what others think here.
--
Michael
On 2019-Oct-17, Michael Paquier wrote:
On Thu, Oct 17, 2019 at 01:04:50AM -0700, Andres Freund wrote:
Wonder if it's worth removing the backward compat ones from master? I
don't quite think so, but...I would vote for the removal so as we'll never see that again in
core. Let's see what others think here.
Agreed. There are enough other API changes that if an external
extension wants to keep using heap_* in their code, they can add their
own defines anyway.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hi,
On 2019-10-17 06:58:27 -0300, Alvaro Herrera wrote:
On 2019-Oct-17, Michael Paquier wrote:
On Thu, Oct 17, 2019 at 01:04:50AM -0700, Andres Freund wrote:
Wonder if it's worth removing the backward compat ones from master? I
don't quite think so, but...I would vote for the removal so as we'll never see that again in
core. Let's see what others think here.Agreed. There are enough other API changes that if an external
extension wants to keep using heap_* in their code, they can add their
own defines anyway.
There's plenty extensions that essentially only need to change
heap_open/close to table_open/close between 11 and 12. And it's
especially the simpler ones where that's the case.
Greetings,
Andres Freund
Andres Freund <andres@anarazel.de> writes:
Hi,
On 2019-10-17 06:58:27 -0300, Alvaro Herrera wrote:
On 2019-Oct-17, Michael Paquier wrote:
On Thu, Oct 17, 2019 at 01:04:50AM -0700, Andres Freund wrote:
Wonder if it's worth removing the backward compat ones from master? I
don't quite think so, but...I would vote for the removal so as we'll never see that again in
core. Let's see what others think here.Agreed. There are enough other API changes that if an external
extension wants to keep using heap_* in their code, they can add their
own defines anyway.There's plenty extensions that essentially only need to change
heap_open/close to table_open/close between 11 and 12. And it's
especially the simpler ones where that's the case.
Would it be possible to wrap them in some #if(n)def guard so that
they're available when building out-of-tree extensions, but not when
building postgres itself?
- ilmari
--
- Twitter seems more influential [than blogs] in the 'gets reported in
the mainstream press' sense at least. - Matt McLeod
- That'd be because the content of a tweet is easier to condense down
to a mainstream media article. - Calle Dybedahl
On Thu, Oct 17, 2019 at 12:34:44PM +0100, Dagfinn Ilmari Mannsåker wrote:
Would it be possible to wrap them in some #if(n)def guard so that
they're available when building out-of-tree extensions, but not when
building postgres itself?
Not sure that's worth the trouble. If there are no objections, I will
remove the compatibility macros.
--
Michael