Re: MaxOffsetNumber for Table AMs

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: MaxOffsetNumber for Table AMs
Дата
Msg-id 20210505182201.72vubonaonoyteks@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: MaxOffsetNumber for Table AMs  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: MaxOffsetNumber for Table AMs  (Jeff Davis <pgsql@j-davis.com>)
Список 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 по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: MaxOffsetNumber for Table AMs
Следующее
От: Andres Freund
Дата:
Сообщение: Re: MaxOffsetNumber for Table AMs