On Tue, Feb 27, 2024 at 10:27:13AM +0900, Michael Paquier wrote:
> On Thu, Feb 22, 2024 at 05:36:00PM +0100, Tomas Vondra wrote:
>> 0001
>> ------
>>
>> I think this bit in pg_proc.dat is not quite right:
>>
>> proallargtypes => '{regclass,bool,int8}', proargmodes => '{i,o,o}',
>> proargnames => '{seqname,is_called,last_value}',
>>
>> the first argument should not be "seqname" but rather "seqid".
>
> Ah, right. There are not many system functions that use regclass as
> arguments, but the existing ones refer more to IDs, not names.
This patch set is not going to be merged for this release, so I am
going to move it to the next commit fest to continue the discussion in
v18~.
Anyway, there is one piece of this patch set that I think has a lot of
value outside of the discussion with access methods, which is to
redesign pg_sequence_last_value so as it returns a (last_value,
is_called) tuple rather than a (last_value). This has the benefit of
switching pg_dump to use this function rather than relying on a scan
of the heap table used by a sequence to retrieve the state of a
sequence dumped. This is the main diff:
- appendPQExpBuffer(query,
- "SELECT last_value, is_called FROM %s",
- fmtQualifiedDumpable(tbinfo));
+ /*
+ * In versions 17 and up, pg_sequence_last_value() has been switched to
+ * return a tuple with last_value and is_called.
+ */
+ if (fout->remoteVersion >= 170000)
+ appendPQExpBuffer(query,
+ "SELECT last_value, is_called "
+ "FROM pg_sequence_last_value('%s')",
+ fmtQualifiedDumpable(tbinfo));
+ else
+ appendPQExpBuffer(query,
+ "SELECT last_value, is_called FROM %s",
+ fmtQualifiedDumpable(tbinfo));
Are there any objections to that? pg_sequence_last_value() is
something that we've only been relying on internally for the catalog
pg_sequences.
--
Michael
signature.asc
Description: PGP signature
