Horton

Re: Sequence Access Methods, round two

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>, Peter Smith <smithpb2250@gmail.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-08-26T04:45:12Z
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 →

  1. Refactor init_params() in sequence.c to not use FormData_pg_sequence_data

  2. Fix comment thinko in sequence.c

  3. Group more closely cache updates for backends in sequence.c

  4. Introduce sequence_*() access functions

Attachments

On Thu, Jun 20, 2024 at 03:12:32PM +0900, Michael Paquier wrote:
> While on it, I have noticed a couple of conflicts while rebasing, so
> attached is a refreshed patch set.

Please find attached a new patch set for the next commit fest.  The
patch has required a bit of work to be able to work on HEAD,
particularly around the fact that pg_sequence_read_tuple() is able to
do the same work as the modifications done for pg_sequence_last_value() 
in the previous patch sets.  I have modified the patch set to depend
on that, and adapted pg_dump/restore to it.  The dump/restore part has
also required some tweaks to make sure that the AM is dumped depending
on if --schema-only and if we care about the values.

Finally, I have been rather annoyed by the addition of log_cnt in the
new function pg_sequence_read_tuple().  This patch set could also
implement a new system function, but it looks like a waste as we don't
care about log_cnt in pg_dump and pg_upgrade on HEAD, so I'm proposing
to remove it on a different thread:
https://www.postgresql.org/message-id/Zsvka3r-y2ZoXAdH%40paquier.xyz
--
Michael