Re: MaxOffsetNumber for Table AMs - Mailing list pgsql-hackers

From Andres Freund
Subject Re: MaxOffsetNumber for Table AMs
Date
Msg-id 20210505182201.72vubonaonoyteks@alap3.anarazel.de
Whole thread Raw
In response to Re: MaxOffsetNumber for Table AMs  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: MaxOffsetNumber for Table AMs
List pgsql-hackers
Hi,

On 2021-05-05 13:32:57 -0400, Robert Haas wrote:
> I don't know what to say here. I think it's unrealistic to believe
> that a very new API that has only 1 in-core user is going to be fully
> stable, or that we can know how it might evolve. I can understand why
> you and probably other people want that, but if somebody figures out a
> way to make some part of core significantly better and it requires
> changing that API, they're going to change the API, not give up on the
> idea.

Yea. I think it would be actively *bad* if tableam were too
stable. tableam is at best an 80% solution to the abstraction needs
(those 80% were pretty painful to achieve already, I don't think we
could have gotten much more initially). If we get cornered into not
evolving the API because of 2-3 external users, we're a) going to live
with a leaky abstraction for much longer b) getting more hesitant to
work incrementally. Both would be bad.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: MaxOffsetNumber for Table AMs
Next
From: Andres Freund
Date:
Subject: Re: MaxOffsetNumber for Table AMs