Re: Remaining calls of heap_close/heap_open in the tree - Mailing list pgsql-hackers

From ilmari@ilmari.org (Dagfinn Ilmari Mannsåker)
Subject Re: Remaining calls of heap_close/heap_open in the tree
Date
Msg-id d8j1rvbr4ff.fsf@dalvik.ping.uio.no
Whole thread Raw
In response to Re: Remaining calls of heap_close/heap_open in the tree  (Andres Freund <andres@anarazel.de>)
Responses Re: Remaining calls of heap_close/heap_open in the tree
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Proposal: Make use of C99 designated initialisers fornulls/values arrays
Next
From: Tom Lane
Date:
Subject: Re: "pg_ctl: the PID file ... is empty" at end of make check