Re: Removing log_cnt from pg_sequence_read_tuple()

On Mon, Aug 26, 2024 at 09:19:06AM -0500, Nathan Bossart wrote:
> I am fine with changes to this function that would allow it to be
> generically useful for all sequence AMs, provided that it can still be used
> for dumpSequenceData(). I only included log_cnt because
> pg_sequence_read_tuple() is intended to be a substitute for SELECT from the
> sequence, but I'm not aware of any real use-case for that column besides
> debugging, which you've already addressed.

Okay, thanks.

> Even if we remove log_cnt, you can still find it with SELECT, too.

The design used in the sequence AM patch makes it possible to assign
custom attributes to the sequence "relation" used for storage, with a
table AM used underneath that may not be heap. The AM callback
plugged into the path used by pg_sequence_read_tuple() (previous
version for pg_sequence_last_value) returns the pair is_called and
last_value, to map to the row of the function used to rebuild the
commands in dumps and upgrades.

> The patch looks reasonable to me. Do you think the name of the function
> still makes sense now that 1) we might have different sequence AMs in the
> near future and 2) it no longer returns everything in the sequence tuple?

Indeed, pg_sequence_read_tuple() would not reflect the reality, some
ideas:
- pg_sequence_read_data
- pg_sequence_get_data
- pg_sequence_data
- More consistent with other catalog functions: pg_get_sequence_data,
as we have already in the tree a lot of pg_get_* functions.
--
Michael