Re: MaxOffsetNumber for Table AMs

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: MaxOffsetNumber for Table AMs
Дата
Msg-id b4cba59081e56e74bd39e7878fc6ff0d70524c64.camel@j-davis.com
обсуждение исходный текст
Ответ на Re: MaxOffsetNumber for Table AMs  (Andres Freund <andres@anarazel.de>)
Ответы Re: MaxOffsetNumber for Table AMs  (Peter Geoghegan <pg@bowt.ie>)
Список pgsql-hackers
On Wed, 2021-05-05 at 11:22 -0700, Andres Freund wrote:
> 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.

Like anything, we make the decision at the time we have a reason to
break something. But why are are exensions disfavored in this
calculation vs. in-core? Isn't it a lot easier to update in-core code
to new APIs?

Evolving the API is one thing, but we should be more careful about
things that could affect on-disk state like ItemPointer
representations. By "more careful", I don't mean that we reject all
proposals; I mean that we don't casually impose new limits in other
parts of the system that happen to work for heapam but will cause table
AM extensions to break.

Regards,
    Jeff Davis





В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Re: COPY table_name (single_column) FROM 'iso-8859-1.txt' DELIMITER E'\n'
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: COPY table_name (single_column) FROM 'iso-8859-1.txt' DELIMITER E'\n'