| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: MaxOffsetNumber for Table AMs |
| Date: | 2021-05-05 17:48:41 |
| Message-ID: | CAH2-Wz=cPMa6bnzkEuniCpskrPUNH-VbM-DNBtHOa2+7XghS8Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, May 5, 2021 at 10:33 AM Robert Haas <robertmhaas(at)gmail(dot)com> 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.
I strongly agree. More generally, we need to decide what downsides
we're willing to live with.
What we have right now has little chance of failing. It also has
little chance of succeeding (except for something like zheap, which
can presumably get by with the heapam's idea of TID).
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2021-05-05 17:56:47 | Re: MaxOffsetNumber for Table AMs |
| Previous Message | Isaac Morland | 2021-05-05 17:34:18 | Re: COPY table_name (single_column) FROM 'unknown.txt' DELIMITER E'\n' |