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

From Jeff Davis
Subject Re: MaxOffsetNumber for Table AMs
Date
Msg-id b4cba59081e56e74bd39e7878fc6ff0d70524c64.camel@j-davis.com
Whole thread Raw
In response to Re: MaxOffsetNumber for Table AMs  (Andres Freund <andres@anarazel.de>)
Responses Re: MaxOffsetNumber for Table AMs
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Re: COPY table_name (single_column) FROM 'iso-8859-1.txt' DELIMITER E'\n'
Next
From: Andrew Dunstan
Date:
Subject: Re: COPY table_name (single_column) FROM 'iso-8859-1.txt' DELIMITER E'\n'