Re: Removing log_cnt from pg_sequence_read_tuple() - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: Removing log_cnt from pg_sequence_read_tuple()
Date
Msg-id ZsyO2vxYIrH-dGN1@nathan
Whole thread Raw
List pgsql-hackers
On Mon, Aug 26, 2024 at 11:11:55AM +0900, Michael Paquier wrote:
> It seems to me that we'd live better without it, at least it matters
> for the sequence AM patch, because some of its callbacks are also
> shaped around the fact that WAL may not be required for sequence value
> computations.  Providing a function that should be rather generic does
> not fit well in this context, still I agree that it comes down to how
> the callbacks are defined, of course.  My point is that the use of WAL
> is something that should be optional, but log_cnt in this function
> makes it a mandatory concept that all sequence AMs would need to deal
> with.

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.  Even if we remove log_cnt, you
can still find it with SELECT, too.

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?

-- 
nathan



pgsql-hackers by date:

Previous
From: Anthonin Bonnefoy
Date:
Subject: Re: Segfault in jit tuple deforming on arm64 due to LLVM issue
Next
From: Robert Haas
Date:
Subject: Re: BitmapHeapScan streaming read user and prelim refactoring