Обсуждение: 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

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

On Fri, Oct 18, 2019 at 10:03:11AM +0900, Michael Paquier wrote:
> Not sure that's worth the trouble.  If there are no objections, I will
> remove the compatibility macros.

Okay, cleanup done with the compatibility macros removed.
--
Michael