Re: Sequence Access Methods, round two

Kirill Reshke <reshkekirill@gmail.com>

From: Kirill Reshke <reshkekirill@gmail.com>

To: Michael Paquier <michael@paquier.xyz>

Cc: Peter Eisentraut <peter@eisentraut.org>, Peter Smith <smithpb2250@gmail.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>

Date: 2025-08-15T07:36:00Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Refactor init_params() in sequence.c to not use FormData_pg_sequence_data
- ba3d93b2e806 19 (unreleased) landed
Fix comment thinko in sequence.c
- 17a3f79f812c 17.0 landed
Group more closely cache updates for backends in sequence.c
- 6e951bf98e2e 17.0 landed
Introduce sequence_*() access functions
- 449e798c77ed 17.0 landed

On Fri, 15 Aug 2025 at 10:47, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Fri, Jun 20, 2025 at 01:50:48PM +0900, Michael Paquier wrote:
> > Rebased as v15, following a report from the CI that the new pg_dump
> > command in the TAP tests needed a --with-statistics switch, like its
> > relatives.
>
> v16 rebased, conflict with naming of pg_dump option --statistics vs
> --with-statistics.
> --
> Michael

Hi!

0001 - LGTM?

0002. WFM, the sole observation I have is that we incorporate sequence
logic to AlterTable utilities, making it less clear of what they
actually do.
I see we already have code path handling CREATE VIEW (in
AlterTableGetLockLevel for example), so maybe it is worth renaming
AlterTable* to AlterRelation*?
It would be really invasive refactoring though, so maybe we should
ignore this slight inconsistency in function names and what they
actually do.
Otherwise LGTM.

I did not review the new 0003-0007 series. Will try to find the time
to do this.

-- 
Best regards,
Kirill Reshke