Date: Mon, 26 Aug 2024 09:19:06 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Removing log_cnt from pg_sequence_read_tuple()
Message-ID: <ZsyO2vxYIrH-dGN1@nathan>
References: <Zsvka3r-y2ZoXAdH@paquier.xyz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Zsvka3r-y2ZoXAdH@paquier.xyz>
Archived-At: <https://www.postgresql.org/message-id/ZsyO2vxYIrH-dGN1%40nathan>
Precedence: bulk

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